[Openid-specs-ab] SIOP Special Call Notes 18-May-21

[Mike Jones]

SIOP Special Call Notes 18-May-21

Kristina Yasuda
Mike Jones
Tom Jones
David Waite (DW)
Tony Nadalin
Edmund Jay
Tobias Looker
John Bradley
Adam Lemmon
Tim Cappalli
Jeremie Miller
Dmitri Zagidulin

Trust Frameworks and SIOP
              DW said that OpenID Connect Federation Entity Statements have interesting properties for SIOP
              He noted that SIOPs may not have a location for hosting metadata
              OpenID Connect Federation defines client metadata and automatic registration
              David is concerned if SIOP ID Tokens could be confused for 3rd Party ID Tokens
                           This might enable injection of false/confusing metadata
              Tobias asked about just-in-time registration
                           Kristina pointed out the OpenID Connect Federation defines Automatic Registration
                           https://openid.net/specs/openid-connect-federation-1_0-14.html#rfc.section.9.1
              Tom talked about user choice of trust authorities
              DW is concerned with the "registration" request parameter being used in unintended ways
              DW said that rather than the client_id being the redirect_uri, it could be a reference to metadata, like in OpenID Connect Federation
              Mike suggested that people to familiarize themselves with OpenID Connect Federation
                           Particularly, Entity Statements and Automatic Registration
                           He noted that there will be a call for working group review of the whole spec in a day or so
                           This will be in preparation for a new Implementer's Draft vote

OpenID Connect for W3C Verifiable Credential Objects
              This spec was adopted as a working group document yesterday
              The authors propose renaming it to "OpenID Connect for Verifiable Presentations"
                           This reflects that it does not directly represent Verifiable Credentials - only Verifiable Presentations

User Consent Issue
https://bitbucket.org/openid/connect/issues/1215/siop-requires-user-consent
              Tom asked whether SIOP V2 is standalone or whether it depends upon OpenID Connect
                           It depends upon OpenID Connect

Issuer Identifier Issue
https://bitbucket.org/openid/connect/issues/1208/siop-v2-dynamic-iss-claim-ref-required
              Adam spoke to using "iss" to identify the wallet
              Tobias said that the provider deployment technology would be changed
              Tobias said that understanding the provider identity is relevant to the trust model
              Kristina asked about discovery
                           Tobias said that it's not a discovery problem, it's about associating to a provider with a distributed deployment
              Mike asked for engineering clarity on the objects we're defining and using
                           He asserted that if a provider is hosted by a third party, it's not self-issued - at least in a protocol sense
                           We may want to define additional characteristics of new kinds of third-party issuers meeting our needs
              DW talked about possibly having chains of issuers and not using https://self-issued.me and openid://
                           We will need to codify how to achieve the properties that we want
              DW said that we shouldn't use the "iss" value to distinguish between different pieces of software
                           There are both information content issues and correlation issues
              Dmitri said that issuers shouldn't represent software instance IDs
                           In Solid, every user has their own server
                           He considers those self-issued, even though they're Web accessible
              Mike said that we need a clear architectural approach
                           It needs to encompass both third party versus on your device OPs and OPs fully controlled by you in both cases
                           They may have different protocol implications even when conceptually grouped
              DW said that we need to define policy elements
                           In part, to prevent things from being invoked without the capability to behave usefully
              Tobias reflected upon PWAs executed by browsers
                           He agreed with Dmitri's and DW's architectural statements
              Kristina asked whether there were objections to not using self-issued.me
                           Mike said that the "iss" currently either identifies the hosted issuer or that it is not hosted
                           Until we have a clearly understood architecture, we should leave this invariant in place
                           John agreed with Mike
                           Dmitri observed that we're using "iss" for protocol routing purposes
                           John said that it has to do with the relationship of the signing key to the subject
                           Mike said that unless the "iss" is self-issued.me, we know that we can get metadata at "iss"/.well-known/openid-configuration
                           Tobias said that wallets could use Web domains to enable hosted metadata
                           John said that key management could potentially be independent of deployment model
                                         We should tease these apart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210519/f5d9b03e/attachment.html>