[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