[Openid-specs-ab] SIOP call notes (2022-Mar-31) - Atlantic call @ 7AM PST
Vittorio Bertocci
vittorio at auth0.com
Thu Mar 31 21:12:30 UTC 2022
thanks Kristina for the summary!
Small adjustment: my point wasn't as much about the IDtoken missing (tho
that's worth discussing too) but about the openid scope missing.
Traditionally, the presence of that scope is what signals to the
authorization server that the request is an openid connect request (as
opposed to a vanilla oauth one) and in some implementations that might
determine whether the request is processed in a code path supporting all
other OIDC specific elements (login_hint, acr_values etc).
I am not strongly opposed in principle to omitting the IDtoken, but I think
that not sending the openid scope might make it harder for existing
providers to add support for the new features. There were various
interesting suggestions on the call (eg use of new response_types) that
might achieve the same outcome.
On Thu, Mar 31, 2022 at 1:47 PM Kristina Yasuda via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:
> *This message originated outside your organization.*
>
> ------------------------------
>
> David Chadwick
>
> Vittorio Bertocci
>
> Daniel Fett
>
> Giuseppe De Marco
>
> Joseph Heenan
>
> Torsten Lodderstedt
>
> Jo Vercammen
>
> David Schudde
>
> Rolson Quadras
>
> David Waite
>
> Tom Jones
>
> John Bradley
>
> Petteri Stenius
>
> Mike Jones
>
> Kristina Yasuda
>
>
>
> - meeting recorded
>
> - Introductions:
>
> - David Schudde from Yorba introduced himself:
> https://yorba.co
> <https://urldefense.com/v3/__https://yorba.co__;!!PwKahg!p9ckMFvnb1hvvBFOaflBCc2uDvDJuUx1zjbMgGS1ca1EJ_yfIUbQqHeFsjU6vAI$>.
> He can be reached at schmudde at yorba.co
>
> - Agenda adopted
>
> - Industry update
>
>
> - W3C VC WG finalized charter for the vc-data-model-v2: Verifiable
> Credentials Working Group Charter (w3c.github.io)
> <https://urldefense.com/v3/__https://w3c.github.io/vc-wg-charter/__;!!PwKahg!p9ckMFvnb1hvvBFOaflBCc2uDvDJuUx1zjbMgGS1ca1EJ_yfIUbQqHeF3uhoIlA$>
>
>
> - If all goes smoothly, the work on it would start within the few
> months, once the charter gets approved
>
>
> - ISO SC17 WG10 working on presentation of mDL over the Internet has
> asked about the stable version of SIOPv2 and OIDC4VP, since the latest
> technical specification from ISO mentions it
>
>
> - WG agreed to work towards publishing Second Implementer’s Drafts of
> SIOPv2/OIDC4VP with all the breaking changes from the First Implementer’s
> Drafts before the publication of the ISO’s specification, so that the
> document referenced by the ISO is very unlikely to have technical breaking
> changes before going to final
> - Editors will start with triaging the issues to have a list of
> potential breaking changes that needs to be prioritized in the WG
> - ISO SC17 WG10 agreed that SIOP features have “parity” with
> mdoc request-response that ISO WG has been working on (huge progress)
>
>
>
> - Editors of the OIDC4VCI spec indicated that they would like to make
> as much progress as possible on the specification before IIW
>
>
>
> - PRs https://bitbucket.org/openid/connect/pull-requests/
> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fbitbucket.org*2Fopenid*2Fconnect*2Fpull-requests*2F&data=04*7C01*7CKristina.Yasuda*40microsoft.com*7C076de138a9434313d7df08da07b1c590*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637830758257768797*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=NvwjmfI*2Fu8jgnKi*2FREuHrJnm0RjZmYT6F5I1XjaCxiY*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!PwKahg!p9ckMFvnb1hvvBFOaflBCc2uDvDJuUx1zjbMgGS1ca1EJ_yfIUbQqHeF2-Y49d0$>
>
>
> - *PR #138 – oidc4vci: pre-authorized code: *
> https://bitbucket.org/openid/connect/pull-requests/138
> <https://urldefense.com/v3/__https://bitbucket.org/openid/connect/pull-requests/138__;!!PwKahg!p9ckMFvnb1hvvBFOaflBCc2uDvDJuUx1zjbMgGS1ca1EJ_yfIUbQqHeFwLrrMPY$>
>
>
> - Torsten introduced the issue.
> - Daniel F. pointed out the need to add new security considerations
> since anyone who can get hold of a QR code could get a VC issued
>
>
> - Mix-Up attack, Brute Forcing attack on the PIN, Authorization code
> injection attack were mentioned
>
>
> - David C. clarified if the PIN was one-time use. Currently it is
> intended to be one-time used, passed via a separate channel
> - WG members are encouraged to review the PR, especially on the
> security aspect
> - We agreed to discuss this PR during the next SIOP call, after
> people had more time to review it
>
>
> - PR #136 – oidc4vci: clarify holder binding:
> https://bitbucket.org/openid/connect/pull-requests/136
> <https://urldefense.com/v3/__https://bitbucket.org/openid/connect/pull-requests/136__;!!PwKahg!p9ckMFvnb1hvvBFOaflBCc2uDvDJuUx1zjbMgGS1ca1EJ_yfIUbQqHeFUMMQkdM$>
>
>
> - merged
>
>
> - Issues #1453, #1452 resolved
>
>
> - We did not cover more PRs, but people are encouraged to review. In
> particular,
>
>
> - PR #145: [oidc4vci] Revises the approach to credential metadata
> publishing: https://bitbucket.org/openid/connect/pull-requests/145
> <https://urldefense.com/v3/__https://bitbucket.org/openid/connect/pull-requests/145__;!!PwKahg!p9ckMFvnb1hvvBFOaflBCc2uDvDJuUx1zjbMgGS1ca1EJ_yfIUbQqHeFVpuUHvo$>
>
>
> - Related to issue #1466
>
>
> - PR #142 oidc4vp: example with anoncreds:
> https://bitbucket.org/openid/connect/pull-requests/142
> <https://urldefense.com/v3/__https://bitbucket.org/openid/connect/pull-requests/142__;!!PwKahg!p9ckMFvnb1hvvBFOaflBCc2uDvDJuUx1zjbMgGS1ca1EJ_yfIUbQqHeFjzEV2sA$>
> - PR #144 updating SIOP v2 definition:
> https://bitbucket.org/openid/connect/pull-requests/144
> <https://urldefense.com/v3/__https://bitbucket.org/openid/connect/pull-requests/144__;!!PwKahg!p9ckMFvnb1hvvBFOaflBCc2uDvDJuUx1zjbMgGS1ca1EJ_yfIUbQqHeFOdhXDz8$>
>
> - Issues
> https://bitbucket.org/openid/connect/issues?status=new&status=open&component=SIOP&component=Verifiable%20Presentation&component=Credential%20Issuance
> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fbitbucket.org*2Fopenid*2Fconnect*2Fissues*3Fstatus*3Dnew*26status*3Dopen*26component*3DSIOP*26component*3DVerifiable*2520Presentation*26component*3DCredential*2520Issuance&data=04*7C01*7CKristina.Yasuda*40microsoft.com*7C076de138a9434313d7df08da07b1c590*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637830758257768797*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=ccce9PXmdGPLv*2FssVmoUlIkXN*2FudMScnnEVJSuAegHQ*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PwKahg!p9ckMFvnb1hvvBFOaflBCc2uDvDJuUx1zjbMgGS1ca1EJ_yfIUbQqHeFd3mwhXc$>
>
>
> - #1467: DID resolver method for OIDC Federation (did:openid:!) wrt
> SIOP v2:
> https://bitbucket.org/openid/connect/issues/1467/did-resolver-method-for-oidc-federation
> <https://urldefense.com/v3/__https://bitbucket.org/openid/connect/issues/1467/did-resolver-method-for-oidc-federation__;!!PwKahg!p9ckMFvnb1hvvBFOaflBCc2uDvDJuUx1zjbMgGS1ca1EJ_yfIUbQqHeFopgnKZ8$>
>
>
> - There is a need to clarify what we would achieve by replacing http
> URL with DIDs as a mechanism to obtain Entity Statements in OpenID
> Federation
> - WG members are encouraged to continue discussion in the Issue
> - Probably better to classify this as Federation related issue
>
>
> - #1470: SIOP Response without ID Token with only a VP Token:
> https://bitbucket.org/openid/connect/issues/1470/siop-response-with-vp_token-only
> <https://urldefense.com/v3/__https://bitbucket.org/openid/connect/issues/1470/siop-response-with-vp_token-only__;!!PwKahg!p9ckMFvnb1hvvBFOaflBCc2uDvDJuUx1zjbMgGS1ca1EJ_yfIUbQqHeFV7feccs$>
>
>
> - Vittorio pointed out that without ID Token, this would not be OpenID
> Connect
> - Torsten made a point that it will still be a protocol on top of
> OAuth, and if we want OAuth/OIDC based protocols to be used, they should be
> as simple as possible to be able to compete with other emerging protocols
> - Rolson shared that as an implementer who started implementing
> SIOPv2/OIDC4VP already having VC/DID implementation, they got VP Token part
> straightforward, but still struggle with ID Token implementation
> - John advised not to use `scope` parameter to indicate that there
> is no need for the OP to return an ID Token, so as to be respectful for the
> existing OP implementations. Probably use response_type, or response_mode.
> This would be especially relevant if we will expand definition of SIOP and
> allow self-issued ID Tokens to be sent using code flow.
> - Torsten mentioned few use-cases where SIOP with code flow would
> make sense – cloud wallet, eIDAS, etc.
> https://bitbucket.org/openid/connect/issues/1399/siop-with-any-oidc-flow
> <https://urldefense.com/v3/__https://bitbucket.org/openid/connect/issues/1399/siop-with-any-oidc-flow__;!!PwKahg!p9ckMFvnb1hvvBFOaflBCc2uDvDJuUx1zjbMgGS1ca1EJ_yfIUbQqHeFrV-qqnQ$>
> - There was support in the chat towards using `response_type`
> - We agreed to explore mechanisms to turn off a feature to return
> ID Tokens, also taking into account existing OIDC implementations, who
> might support self-signed ID Token features
>
>
> - From the chat
>
>
> - Tom Jones: “The PEMC is creating a set of requirement for any
> identifier that is send from a verifier to a wallet in order to assure the
> the user can make a valid conset to release data - would the SIOP be
> interested in such requirements? They would apply to SIOP and well as
> 18013-5 if adopted. My own take on this would be that any identifier
> contained in the requiest would be guaranteed (tbd) by the verifier to be a
> valid representation of the request. For example if square the request they
> would guarantee the identifier of the merchant in the request”
> - Relevant URL?:
> https://kantarainitiative.org/groups/PImDL-work-group/
> <https://urldefense.com/v3/__https://kantarainitiative.org/groups/PImDL-work-group/__;!!PwKahg!p9ckMFvnb1hvvBFOaflBCc2uDvDJuUx1zjbMgGS1ca1EJ_yfIUbQqHeFflC55tE$>
>
>
>
> Next SIOP call is April 7th 8am PST.
>
>
>
> Thank you!
>
> Kristina
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20220331/69262a79/attachment.html>
More information about the Openid-specs-ab
mailing list