Add 'format' to stream config and normative examples in CAEP

[FragLegs]

This PR deals with two different uses of format

1. It removes format from the stream configuration. Here, format means that the stream should expect to only deal with subjects using this format identifier. This closes issue We should include "format" in at least one of the stream configuration examples #54
2. It adds format to the CAEP event normative examples. Here, format is used to denote that the subject in the event is a complex subject. We didn't update this file when we created PR Added format field to complex subjects and updated examples #71

[independentid]

I think there is a general issue of concern that needs more discussion. AFAIK the format is a configuration issue for streams that says what identifier formats and attributes will be used to identify subjects in feeds. SCIM has some variability especially considering ldap and azure to cloud.  I recall google IDP had no clear what to identify subjects as they vary dramatically between RPs.  The the important functionality is that is represents how the issuer and audience have agreed to identify subjects. Yes you could force a single value in the standard but that makes the standard fragile because it becomes limited in usability. For scim I had proposed “Id” and “externalId” is this is what the scim protocol standardizes.  Many have complained that scim is too limited. Others point out that some receivers will not be scim but other systems like ldap or security AI. Subject ID spec and format became the became the way to move forward.  The downside remains how can one build an infinite number of parsers?   The trade off being so you build ssf servers one set of specs and cases or do you add extensibility to handle new format cases over time.  After all this is what consultants and integrators do. PhilOn Jul 28, 2023, at 9:47 AM, Apoorva Deshpande ***@***.***> wrote: @appsdesh commented on this pull request. In openid-sharedsignals-framework-1_0.md:

@@ -887,7 +887,8 @@ Authorization: Bearer eyJ0b2tlbiI6ImV4YW1wbGUifQo=

"urn:example:secevent:events:type_2", "urn:example:secevent:events:type_3", "urn:example:secevent:events:type_4" - ] + ], + "format": "email" Thanks for clarifying things for me @FragLegs! Just like "subjects" are getting removed from the status, I think it would add the value to fix this abstraction/layering issue before the spec is sent for approval. On that note, it may not be needed to update examples at this point. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[timcappalli]

@FragLegs if we're saying that sub_id needs to be used, should we refactor all of the examples to use sub_id?

[FragLegs]

@FragLegs if we're saying that sub_id needs to be used, should we refactor all of the examples to use sub_id?

I think that work is being done in #82 right?

[timcappalli]

lgtm