You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This work suggests using a different set of profile identifiers from those used in SAML binding. I understand why it's done here (OIDC Fed doesn't have the notion of entity category), but I think we need examine this further:
These profile identifiers convey information about the entity (is it called entity in OIDC land?) it annotates. In theory, we want to compose these values so that they express as much as possible the semantics.
So perhaps instead of /rp and /op, there is opportunity to describe the relationship that particular party has with the profile, perhaps /member-of, /conforms, /supports ?
Yes, this line of investigation will probably lead us to re-examine how things are done in SAML as well. Scott Cantor, during an early Framework Registration WG call, had explained the original vision and concerns that drove the creation of entity categories. We should examine whether there is opportunity to (re)line things up a bit.
(Tossing Grande)
I am not creating a separate issue about this because it really is tangential to this document... but... if we are talking about creating profiles that are transport (SAML, OIDC, etc) agnostic, what happens if we introduced a much different paradigm, say, digital wallets?
The text was updated successfully, but these errors were encountered:
Re: 6.2.1 Syntax
This work suggests using a different set of profile identifiers from those used in SAML binding. I understand why it's done here (OIDC Fed doesn't have the notion of entity category), but I think we need examine this further:
These profile identifiers convey information about the entity (is it called entity in OIDC land?) it annotates. In theory, we want to compose these values so that they express as much as possible the semantics.
So perhaps instead of /rp and /op, there is opportunity to describe the relationship that particular party has with the profile, perhaps /member-of, /conforms, /supports ?
Yes, this line of investigation will probably lead us to re-examine how things are done in SAML as well. Scott Cantor, during an early Framework Registration WG call, had explained the original vision and concerns that drove the creation of entity categories. We should examine whether there is opportunity to (re)line things up a bit.
(Tossing Grande)
I am not creating a separate issue about this because it really is tangential to this document... but... if we are talking about creating profiles that are transport (SAML, OIDC, etc) agnostic, what happens if we introduced a much different paradigm, say, digital wallets?
The text was updated successfully, but these errors were encountered: