[Openid-specs-ab] Notes SIOP special call (2021-09-16)

Kristina Yasuda Kristina.Yasuda at microsoft.com
Mon Sep 20 22:33:43 UTC 2021


Torsten Lodderstedt
Justin Richer
Mike Jones
Anthony Nadalin
David Chadwick (notes)
Jeremie Miller
Dmitri Zagidulin
Bjorn Hjelm
Guiseppe De Marco
Stephane Durand
David Waite
Pamela Dingle
John Bradley
Kristina Yasuda
Regrets: Oliver Terbu

Thank you, David C. for taking notes!

  *   Note-taking: We discussed making a list of attendees and cycle through them for note taking. The above list can be taken as the initial one.
  *   Renaming the special calls: We discussed renaming the group. Suggestions were OIDC for SSI, OIDC for Decentralised IDs, and VOID (Verified OID). Kristina will send out a call for names to the list.
  *   Events/External orgs - EIC 21
     *   At OpenID Workshop, Torsten and Kristina presented SIOPv2, OIDC4VP, and claims aggregation specification family, and did a demo of a prototype. Slides are here, with the pointers to the demos on Youtube: https://openid.net/wordpress-content/uploads/2021/09/OIDF_OIDC4SSI-Update_Kristina-Yasuda-Torsten-Lodderstedt.pdf
     *   On Wednesday, Kristina did a deep-dive on SIOP and OIDC4VP. Recording is here: https://www.kuppingercole.com/watch/eic2021-yasuda-self-issued-oidc4ssi
     *   David Chadwick reported on the Thursday afternoon session Decentralized Identity for the Enterprise from Esatus.
        *   Attendees were able to download the Esatus Wallet, and then install a VC and use it to access a Wordpress web site. Esatus uses the Sovrin permissioned blockchain with public read access to store issuer DIDs, schemas and VC types. The demo system allows anyone to register as an issuer and does not have a proper functioning trust regime (but this can be added). There was a demo of SOWL, a web based system for creating new VC schemas and VC types and storing these on the Sovrin test blockchain. He then created a new Applications in SOWL that will use VCs for access, through defining Entitlements and Rules. We were shown how you can build a Wordpress web site using the SAML protocol for login, but instead of un/pws, VCs are sent from the user's wallet. SOWL supports OIDC, SAML, LDAP and SCIM. One negative feature is that the wallet has to be configured with the correct Sovrin blockchain to talk to, as there are many of them in the wild. If the wrong one is chosen the demo will not work. This shows a weakness of the current blockchain based system. Why not publish the VC meta data on the web instead of in a blockchain, and then wallets would not need to choose between blockchains. A member of the audience said the current system would not pass the Granny test. The performance was also dire.
  *   PRs
     *   https://bitbucket.org/openid/connect/pull-requests/50 - ready to review
        *   Jeremie proposed using PAR in SIOP response to solve a problem when redirect URI from RP to SIOP is too huge. PAR spec have addressed this issue - solution is to send a HTTP Post to the RP and then do the redirect. Jeremie said this could be an enhancement to the current cross-device flow SIPO proposal, without reusing redirect_uri.
        *   Torsten asked about the difference with the code flow where OP sends a code and RP fetches the result - in SIOP flow, RP does not have a way to get back to a particular SIOP instance after receiving the response.
     *   https://bitbucket.org/openid/connect/pull-requests/44 - ready to review
        *   Torsten updated the PR to reflect discussions in DIF PE calls, proposing to include presentation_submission in the signed ID Token for both use-cases when VP is returned as a VP Token of embedded in the ID Token.
        *   David C. said that his developers don't need presentation_submission field because, VP schema can replace it. Further discussions needed.
     *   https://bitbucket.org/openid/connect/pull-requests/49 - merged and closed Issue #1267 (https://bitbucket.org/openid/connect/issues/1267/successful-client-registration-response)
     *
     *
  *   Issues
     *   https://bitbucket.org/openid/connect/issues/1263/other-client-id-values-than-redirect-uri
        *   DW is preparing a PR by the end of the week of Sept. 20.
        *   Torsten suggested working on a concrete solution to make client_id resolvable before removing any fields.
        *   Problem addressed: unless SIOP has a pre-existing relationship/pre-exchanged keys with the RP, registration data is not authoritative
        *   Proposed solution: client_id would be resolvable by scheme, converting client_id into a .well-known URL, grabbing self-signed JWT and potentially evaluating trust chain. Alternative solution would be to decide which keys can can be used in SIOP's non-authoritative context.
        *   Torsten noted that we agree that in SIOP model it does not make sense to add redirect_uris to the metadata, but does not see an issue with adding other metadata like format in the request itself. OpenID used to have a similar callback mechanism called RP discovery and it has caused a lot of implementation issues - responsiveness, stability, latency of the OP depends onthe RP.

        *   Removing registration_uri does mean pretty limited alternatives to the registration and that might be a problem
        *   Dmitri suggested having resolvable client_id as a fallback option - check for registration_uri first for latency and stability issues, and if not available try resolving client_id, plus cashing.
        *   DW pointed out that .well-known is actually controlled by the administrator of the domain, but with arbitrary URIs like redirect URIs, need to worry about someone trying to compromise the system.
        *   Dmitri noted that we can use the service endpoint of a DID coupled with well known endpoints. This will allow the metadata to be retrieved from DIDs - need to discuss with a larger DID community in defining this mechanism in detail.
        *   Torsten asked what would be the benefit of supporting DIDs as client_ids in addition to OpenID Federation's existing public key rotation mechanism. Dmitri said DIDs uncouple hosting of metadata from DID documents. David Waite said DIDs are more flexible than using HTTPS URLs. But this flexibility can disadvantage obtaining metadata (too many options).
        *   Torsten noted that this approach seems to draw a clear line between the key management and hosting a metadata

     *   https://bitbucket.org/openid/connect/issues/1261/how-does-rp-determine-sub-type
        *   DW working on a PR by the end of the week of Sept. 20th
        *   Resolvable subject identifiers - similar approach to resolvable client_ids. The subject will be a URI within SIOP that is resolvable to an authoritative JWKS, and that JWKS be used to sign the id_token. would be different mechanism depending on URIs - DIDs and HTTPS URLs
        *   2 possible approaches with HTTPS URLs - 1/ namespace the thumbprint and keep including the subject, closer to a self-certifying identifier; 2/ JWK URI, Base64URL encoded JWK, inline the key similar to did:key
        *   potentially main point of SIOP is to define resolvable subject identifiers and use them instead of the issuer key to protect the message
        *   Torsten asked why not just pass a subject type identifier in the ID Token. DW replied that the simplest solution would be to turn thimbprint into a URI format, so that you can look directly at the subject field to determine the type.

     *   https://bitbucket.org/openid/connect/issues/1240/openid-provider-as-collective
        *   Resolved, being addressed in resolvable subject identifier issue
     *   https://bitbucket.org/openid/connect/issues/1209/for-migration-should-support-multiple
        *   Resolved, since resolvable subject identifiers eliminate the possibility of a traditional OP needing to support multiple subject values in parallel
     *   https://bitbucket.org/openid/connect/issues/1215/siop-requires-user-consent
        *   Resolved. Tom Jones to propose an alternative approach
     *
     *
     *
     *

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210920/08e582b1/attachment-0001.html>


More information about the Openid-specs-ab mailing list