[Openid-specs-ab] SIOP Special Call Notes 10-Feb-22

[Mike Jones]

SIOP Special Call Notes 10-Feb-22

Mike Jones
Kristina Yasuda
Torsten Lodderstedt
Joseph Heenan
Petteri Stenius
Bjorn Hjelm
David Chadwick
Brian Campbell
Kenichi Nakamura
Daniel Fett
Jo Vercammen
David Waite

Approved Implementer's Drafts
              The two approved SIOP-related Implementer's Drafts are:
              https://openid.net/specs/openid-connect-self-issued-v2-1_0-ID1.html
              https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0-ID1.html

Open Pull Requests
              https://bitbucket.org/openid/connect/pull-requests/
              PR #120: Issuer Handling SIOP
                           This was also discussed on the preceding Connect call
                           Vittorio had asked on a previous call why use cases where "sub" and "iss" are different aren't interesting
                           Torsten is interest in having an attestation about the software producing the ID Token
                                         This would be different issue
                                         The IETF RATS and EAT working groups are doing attestation-related work
                           Torsten said that having "iss" == "sub" would enable an ID Token to be a Verifiable Presentation
                           George said that in the third-party case, the "iss" is used to validate the metadata and keys of the issuer
                           George said that we should have a non-normative note clarifying the motivations
                           Mike observed that if "iss" doesn't point to .well-known/openid-configuration, we lose the ability to retrieve metadata from the issuer
                                         Torsten said that in SIOP v1, we already couldn't do this
                                         Mike agreed to file a comment on issue #1400 about this
              PR #101: Fetching presentation definitions from a remote repository
                           Torsten filed a comment on the organization of the PR
                                         David agreed to reorder the text as suggested by Torsten
                           Torsten also filed a comment on the metadata values
                                         David disagreed with him
                           We agreed that request by value should be the default
                           People are requested to comment in the PR on the metadata syntax
              PR #124: [oidc4vci] clarify sub value in the ID Token Issue #1426
                           We discussed this with issue #1426, as recorded below
              PR #107: Support for federations using the termsOfUse property
                           David asked about using "anyof"
                           Torsten said that there are numerous issues with parsing and the specification of it
                           Kristina said that PE v2 is still being actively worked on
                           Torsten said that PE doesn't mention "anyof"
                           Torsten suggested simplifying the example to have a single value
                           Torsten said that PE doesn't support what David wants and that would have to be addressed in the PE spec
                           Kristina asked for David to provide an assessment of how stable PE v2 is
                                         David agreed that v1 is more stable
                                         He said that v2 will be vastly superior, as it defines an MTI core and optional features
                                         Torsten said that v2 format functionality is better and needed
                                         Torsten doesn't want to have to define an OpenID profile of PE v1

Open Issues
              https://bitbucket.org/openid/connect/issues?status=new&status=open
              #1426: Clarification of "sub" value
                           Torsten said that everything about "sub" in OpenID Connect Core still applies
                           George is worried about ephemeral identifiers
                           Torsten said that this the "sub" in the issuance draft - not the "sub" in the SIOP ID Token
                           Implementers want to know what to put in the "sub" value
                           Daniel said that whatever is in the "sub" should be about the End-User
                           Kristina suggested clarifying that everything about the Connect ID Token applies
                           She also said that there may be cases in which an ID Token isn't needed
                                         Daniel said that the ID Token is needed to contain the "nonce" in the reply
                           Torsten said that the alternative is to turn this into a pure OAuth flow
                           Kristina will update the PR
                           She will file a separate issue about whether to turn this into a pure OAuth flow

              #1429: Replace JWK Thumbprint URI with JWK URI
                           David prefers to send the entire key as a URI
                           He said that RPs that want a stable identifier could create one by applying the JWK Thumbprint rules
                           Mike said that having the "sub" be a stable identifier of limited size is important
                           Mike said that having RPs compute the stable identifier from the "sub" would be an unnecessary departure from Connect Core semantics

Next Call
              The next Connect call will be on Monday, February 14, 2022 at 3pm Pacific Time
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220210/bd27f09e/attachment.html>