[Openid-specs-ab] SIOP special topic call minutes (2021-07-08)
Kristina.Yasuda at microsoft.com
Fri Jul 9 03:04:35 UTC 2021
- IPR reminder & introductions/re-introductions
- Agenda adopted
- DIF Presentation Exchange/OIDF WG update
- Notes: https://hackmd.io/zKvmu5erTC-osNeU-XqCCw?both
- Next call: 8/4 (Calendar placeholder attached)
- Agreed on the direction to take modular-approach, where PE will consist of modules (input_descriptor, format, presentation_submission, etc.) and OIDC4VP draft will outline how these modules be used in OIDC
* We walked through what each PR is about - please review. two are OIDC4VP related and two are SIOP V2 related
* SIOP V2
* editorial, assigned to Kristina to modify in the next PR to SIOP V2 draft
* Resolved in PR #31<https://bitbucket.org/openid/connect/pull-requests/31>
* David C. mentioned that we also need to address a use-case where one request from RP is expected to be fulfilled by VCs from several issuers
* Jeremie said they have thought about it. The use-case would require all wallets to co-operate, and use PF level features to talk to each other, and ask the operating system to open another wallet if that is required to fulfill the request. (on iOS, called action)
* DW noted that this is a combination of what is possible today, and is not a standard discussion - very limited by what APIs platforms allow to interact with
* Assigned to Jeremie & DW wrt implementation guide, and Kristina to tune the language in PR #25<https://bitbucket.org/openid/connect/pull-requests/25>
* Probably a good idea to file a separate issue on multiple wallets fulfilling a one request
* A lot of use-cases exist where RP and SIOP are on the different devices, inspired by mDL.
* Alen commented that they have faced the similar use-case, and the only issue they found was phishing, if the user using SIOP accesses malicious RP's endpoint
* Oliver noted the previous discussion in DIF: https://github.com/decentralized-identity/did-siop/issues/3
* Torsten noted that SIOP cross-device flow communicates back to the RP, not using Form POST method
* Mike said we need to know who are the players in cross-device flow
* Assigned to Torsten. Planning to do the PR to clarify the idea. Security analysis needed. CIBA and device flow might be used as alternatives
* Currently how RP can determine which subject identifier type (jkt or which did method) is used in particular ID Token.
* We discussed two approaches: 1/ add additional metadata `sub_type_used` to the ID Token, 2/use URI as a sub, so that RP can determine sub's type by looking at sub itself
* Mike said it would be easy to define JWK thumbprint as URN. Adam has been considering that last year.
* David C. suggested using HTTP URL with a DNS name, with DNS name being VPC, but it was pointed out that using current sub types would be sufficient
* Assign to Kristina to describe the way the relying party determines subject_identifier_type as part of the ID token validation
* Currently, sub_jwk is required even when DID is used in a sub, because of backward compatibility with SIOP in OIDC.Core ch.7.
* Torsten suggested that because SIOP already changes the way RP interprets sub, no need to worry about backward compatibility. No objections were made.
* People commented in favor of not requiring sub_jwk when DID is used as a subject type, as it would be a duplication of the keys. and lead to the unspecificed behavior is a key in sub_jwk does not match the key based on DID resolution.
* We discussed how can SIOP can declare which key is used to sign a particular ID Token.
* DID Document can include several keys and leaving it to the DID Document to specify purpose of each key is a problem.
* Torsten and Kristina suggested kid in the header to determine concrete key.
* Oliver suggested putting DID URL in kid (e.g., did:example:alice#signing-key). DW said he would expect kid to be just 'signing-key', as the kid in JWS today doesn't refer to the JWKS URL. Mike agreed with the JWKS URI observation. Passing the keys by reference vs by value.
* Jeremie pointed out that for the use-cases when external key look up is not needed (ie sub is not a DID), sub_jwk needs to be included
* The WG agreed to continue the discussion.
* We did not have the time to cover, please review: https://bitbucket.org/openid/connect/issues?status=new&status=open&component=Verifiable%20Presentation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%3Fstatus%3Dnew%26status%3Dopen%26component%3DVerifiable%2520Presentation&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C1ac37ea74cf74792ba1508d9410101c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637612296111627765%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JMU%2BW33L8QnmPq5Nb0q2vBWzwBt9XMwx%2BAKgFfpA0sc%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Presentation Exchange_OIDF special sessions.msg
Size: 41472 bytes
Desc: Presentation Exchange_OIDF special sessions.msg
More information about the Openid-specs-ab