[Openid-specs-ab] Spec Call Notes 27-Jan-22
Mike Jones
Michael.Jones at microsoft.com
Thu Jan 27 20:20:24 UTC 2022
Spec Call Notes 27-Jan-22
John Bradley
Giuseppe De Marco
Joseph Heenan
Filip Skokan
Brian Campbell
Thomas Bellebaum
Bjorn Hjelm
David Chadwick
Kristina Yasuda
Mike Jones
Federation Spec Discussions
Roland discussed the state of the Federation spec
He talked about Tom Jones not liking our use of the term Trust Mark
Roland asked if we wanted to rename Trust Marks to Compliance Marks as a compromise
John said that what we're calling Trust Marks matches most people's understanding of what a Trust Mark is
Our Trust Marks are signed JSON documents. Roland said that Tom thinks they should just be URLs.
John doesn't think that Trust Marks being signed JSON would stop the US healthcare system from using them
If they want to just use a URL, they can simply pull the URL out of the JSON object
Mike pointed out that Tom isn't on the call and we're already discussing this in the issues
Giuseppe said that he'd like the decisions to be made soon so the spec is stable
We decided on the call not to change the name - see issue #1394
Federation Issues
https://bitbucket.org/openid/connect/issues?status=new&status=open&component=Federation
#1368: [federation_api] fetch entity statement - issuer paramenter is really required?
Roland said that this is about leaving an issuer out of the request - not a response
John said that the subject you're asking about is always the end entity
The party that's proxying the request shouldn't be called the issuer
David said that in the TRAIN model, this is called the proxy
Mike said it seems like we don't need this request parameter and we shouldn't call it the issuer
John said to call it the "resolver"
David said that it's important that it be signed by the resolver or the subject
John said it's good to say who's asking for debugging purposes, even if that information isn't secured
Roland said that the requester should be in the audience
Roland agreed to make these changes. After that, we should re-review the descriptions.
Federation PRs
https://bitbucket.org/openid/connect/pull-requests/
PR #111: Evaluate Entity Statement for any subject
Roland said that there is a "list" operation that lists subordinate entities
Roland said that the subject parameter is the entity we're asking about
That answers Mike's question about how you know what the response is about
John asked if we need an on-behalf-of in some cases because the entity isn't the resolver
Where in the response is the subject of the query?
Roland said that this is the subject claim
John said that he would call this the entity
This is part of the description to be changed per the discussion of #1368
Open Issues
https://bitbucket.org/openid/connect/issues?status=new&status=open
#1395 usage of id_token_hint in OIDC.Core
John said that the wielder would need some kind of proof-of-possession mechanism
John asked whether this should even be called an ID Token
Brian said that this would be a misuse, requiring ignoring RFC-level REQUIRED security validation actions
He thought that having a different token intended for this purpose would be far better
David said that the thing we're talking about feels more like a Verifiable Credential
Kristina said that there are far more issuers of ID Tokens than VCs at this point
John said that what you want is some kind of federated access token - not an ID Token
The claims needed can be in the access token
Outstanding Implementer's Draft Approval Votes
https://openid.net/foundation/members/polls/261 - prompt=create
https://openid.net/foundation/members/polls/266 - SIOPv2 and OIDC4VP
Please participate!
Next Call
The next Connect call will be Monday, January 31, 2022 at 3pm Pacific Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220127/6105ae60/attachment.html>
More information about the Openid-specs-ab
mailing list