[Openid-specs-ab] SIOP Special call notes 27-April-2021

Kristina Yasuda Kristina.Yasuda at microsoft.com
Tue Apr 27 17:53:12 UTC 2021

Oliver Terbu
Mike Jones
Dmitri Zagidulin
Jo Vercammen
Jan Vereecken
Nat Sakimura
Andrew Hughes
Torsten Lodderstedt
Adam Lemmon
Kristina Yasuda

  *   Decisions
     *   Updated Call schedule: weekly SIOP calls alternating between Atlantic and Pacific timezones
        *   Bi-Weekly Pacific SIOP calls on the usual time (7AM JST, 3PM PST) on Tuesday starting May 4th -> 18th -> June 1st -> ...
        *   Bi-Weekly Atlantic SIOP calls on the time as the first call today (11PM JST, 7AM PST), but on Thursday, starting May 13th -> 27th -> June 10th -> ... (filling in the empty slot for the bi-weekly Atlantic Connect calls)
        *   OIDF and DIF calendars will be updated soon. You should have already received invites from me.
Requesting and presentating of VCs using OIDC aka OIDC4VCOs
The editors of the current draft<https://github.com/awoie/vp-token-spec> will contribute the updated version which allows for both options - embedding VP inside the ID Token and returning VP separately from ID Token as a newly defined VP Token artifact.
The WG will gather implementation feedback with a goal of making a decision on which option to adopt
        *   This specification will be separate from SIOP V2 draft because it applies to not just SIOP flows, and should remain in close touch with issuance of VCs using OIDC work

  *   Introductions and Reintroduction
     *   Meeco<https://www.meeco.me/> is joining OIDF
        *   Jo and Jan from Meeco joined the call
     *   Andrew Hughes from Idemia joined the calls - vast experience also in ISO/IEC SC27 WG5, SC17 and FIDO
  *   Meeco Implementations
     *   Implementation in Australia to issue certain credentials (driver licenses) in a way that can be used to verify workers in certain industries
     *   Another use-case where Verifiable Credential is in a wallet and users present it in a liquor shop as a VP.
     *   OIDC is used for issuing of the credential. Flow being used is third party flow, not SIOP flow
     *   broker translates VCs into OpenID Flow and verifies them.
     *   chose OIDC to solve the configuration problem, not to eradicate central IdP as in SIOP
  *   SIOP-related sessions @ IIW recap (some happened during 2021-04-26 Connect WG call)
     *   OIDC4VCOs: https://docs.google.com/presentation/d/1a6xAY9NKNON49Atcv9PtB3F0NdmJ4wDHMrVSPaA2-lI/edit#slide=id.p
     *   OpenID Connect Claims Provider: https://docs.google.com/presentation/d/1w-rmwZoLiFWczJ4chXuxhY0OsgHQmlIimS2TNlce4UU/edit#slide=id.gd331646bb4_0_21
     *   SIOP use-cases: https://docs.google.com/presentation/d/1a0C4HvVYwwwDqSw3tgPNhy9Iqyufy9oZdnMgl7rQ9Vc/edit#slide=id.p
     *   SIOP Chooser: https://docs.google.com/presentation/d/1OaMecHecTUexv1skJZoYzJoHKYH8H03REFpFstLRjPg/edit#slide=id.gd2c45a9dcd_7_0
  *   Full discussion on Requesting and presentating of VCs using OIDC aka OIDC4VCOs
     *   Torsten summarized the develpment to-date
        *   During the IIW session, option 2 on using aggregated/distributed claims syntax got voted out.
        *   Participants (over 60 people) were split between embedding VP in the ID token and separate VP Token approach (10 votes to 8 votes)
        *   Vote seems to show a balance between the number of people focussing on (1) ease of adoption in existing implementations vs the number of people focussing on (2) the best technical solution.
           *   Clarification was requested why VP token approach is considered more "robust".
        *   Initial research showed that SIOP implementations are not using traditional libraries, and are writing code from scratch, so implementing VP Token should not be an issue; and some providers are willing to try implement VP Token approach
        *   Proposal to carry on with a version that allows for both options and gather implementation feedback and data and make a decision
           *   would have to define generic container to convey a claim as a same syntax to use when embedding inside the ID token and as a VP token
           *   something like an array with objects containing a format identifier and the actual payload (+ potentially some additional metadata).
     *   Mike commented he is ok, and this reminds him of RFC6750 Bearer Token spec with three ways. It hurts interoperability but allows people to do what they wanted to do.
     *   Oliver and Dimitri raised a question how do we structure the related specs?
        *   Mike suggested that claims definitions and separate artifact definitions should be in the same spec. Should not be part of SIOP because this is independent from SIOP model.
        *   Torsten suggeted this work should be alidned with VC issuance using OIDC.
        *   Nat agreed, no one objected.
     *   Nat asked from which endpoint the VP token will be returned.
        *   Torsten clarified that depends on the grant/response_token. VP token is to be returned as part of authentication response for both SIOP and code flow together with ID Token.
        *   Returning VP Token from a userInfo or newly defined endpoint could also be considered later. Claims aggregation and Credential Provider draft defined new endpoint, which could potentially be reused.
     *   Torsten expressed concern regarding issuing credentials in the backchannel using bearer tokens, and not sender constrained access tokens
     *   Mike asked if we would need to return VCs and to define VC Token too
        *   Oliver and Dimitri argued that VCs should not be returned by themselves - just like claims have to be included inside the ID token
        *   might be no need for VC_token, because if you want to issue a verifiable credential, you can put it inside a VP token
     *   The WG agreed editors will contribute an updated draft to the WG, get recommendation from SIOP Special call to adopt it and officially ask Connect WG to adopt it, so that the draft moves to an official Bitbucket repository and issues can be raised against it

  *   Events: OIDF Workshop Presentation on April 29th
     *   please review the deck planned to be used: https://drive.google.com/file/d/1I7QYS8tFd2KHpGKZ0x_8E-95Gc2CeKp7/view?usp=sharing

I will also put these notes in the wiki.


差出人: Kristina Yasuda <Kristina.Yasuda at microsoft.com>
送信日時: 2021年4月14日 13:27
宛先: openid-specs-ab at lists.openid.net <openid-specs-ab at lists.openid.net>
件名: SIOP Special call notes 13-April-21 Fw: [Openid-specs-ab] OpenID Connect for W3C Verifiable Credential Objects

Hi All,

Please find below the note from today's SIOP Special call.
We have three options on how to include W3C Verfiable Credential Objects in OIDC - separate tokens, credential sources (library), and custom claim names. Attaching the notes to an email with the relevant slides and links that Torsten kindly shared.

Looking forward to the discussion at IIW.

Note that the next call will be on 27th at Europe-friendly Atlantic time (7am PST, 5pm CET, 0AM JST).

PS Notes can also be found in the Wiki: https://bitbucket.org/openid/connect/wiki/SIOP%20Special%20call%202021-04-13


Mike Jones
Adam Lemmon
Tom Jones
Anthony Nadalin
Justin Richer
Tim Cappalli
John Bradley
Jeremie Miller
Torsten Lodderstedt
Oliver Terbu
David Waite
Vittorio Bertocci
Tobias Looker
Bjorn Hjelm
Edmund Jay
Kristina Yasuda

  *   Proposal to set up a Europe-friendly SIOP special call time
     *   same time as Atlantic calls (7am PST, 5pm CET, 0AM JST) on Tuesday, bi-weekly cadence, starting 27th April.
  *   Update for #1212 - Universal URL Based Discovery for SIOP<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%2F1212%2Funiversal-url-based-discovery-for-siop&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C3a64af5de9524b4ea87b08d8fed02d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539517352090693%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5eeT6I4YFavEacR6f90jGYDFz9%2BgLqY5lL76cVV2k%2Bk%3D&reserved=0>
     *   Jeremie - working on it; agreed to rename the issue to "SIOP Chooser"
     *   First implementation by Tom Jones - seems to work plan to use MSFT hello as a proof of presence
     *   Some conversation happening over DIF C&C channel
  *   Defining JWT Claims to represent W3C Verifiable Credentials objects discussion
     *   Summary of the discussions up to date (see Spec Call Notes 8-Apr-21, Spec Call Notes 12-Apr-21 and ML for details)
        *   Mike: vc vp claims defined in vc-data-model spec do not encompass entire VCs VPs, rather the function to contain JWT claims specific to VC alongside other JWT claims
        *   Dmitri Zagudulin gave input that there are implementations that embed entire VC VPs
        *   the question being discussed not is do we want IANA registered claims or data structure with dictionaries like aggregated/distributed claims syntax.
        *   VC/VPs can be embedded in a JWT as long as their processing rulesare compatible with the enclosing JWT
     *   Torsten presented early thinking on using aggregated/distributed claims for VCs/VPs<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fawoie%2Fvp-token-spec%2Fpull%2F23&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C3a64af5de9524b4ea87b08d8fed02d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539517352100649%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5WdZrafx04rjXsviI0kjCPQgYQ5VkrLw44anagSsI%2Bk%3D&reserved=0> (presentation slides sent in a separate email) :
        *   Had a discussion with Mike, Kim, Oliver and Kristina on the specification how to request and convey VC objects (VCOs - includes both VC and VP) in OIDC
        *   VCOs can come from wherever - ID Token and UserInfo endpoint,etc.
        *   Requests are controlled by the claims parameters, not to overload or invent new response types
        *   initial thinking was to have a separate artfact VP token, to compartmentalize different kind of tokens to prevent processing issues especially with JWT and JSON-LD.
        *   There was also an idea to to use ID Token as VP, but they have different processing rules.
        *   Current option is JWT claims that are arrays and can provision more than one VCO.
        *   Torsten showed the examples of how vp_jwt and vp_ldp will be embedded in the ID token.
        *   Torsten also showed how aggregated and distributed claims syntax can be used to return VCOs, using the dictionary that maps to the source
     *   Tony said that there is a need for a userinfo endpoint support in SIOP.
     *   Tom said that there is no use-cases where VC is sent back directly, without being included in a VP.
        *   Kristina and Torsten agreed, and said it would be clearer once we have more implementation experience.
     *   Tony clarified the difference between vc-data-model defined vc vp claims and new claim names used in these slides.
        *   Tobias, DW, Mike and Kristina clarified that vp_ldp proof is a container that includes entire VCO and is independent of vc vp claims defined in vc-data-model that are used inside the VCO to contain @context, type, etc.
        *   Note from Kristina: vc-data-model spec language is one of the reasons of the confusion because vp claims is defined as the object that "contains the verifiable presentation<https://www.w3.org/TR/vc-data-model/#dfn-verifiable-credentials> according to this specification", but in the description above the definition it says that vp claim only "contains those parts of the standard verifiable presentations<https://www.w3.org/TR/vc-data-model/#dfn-verifiable-presentations> where no explicit encoding rules for JWT exist" and the examples follow the description and only VP specific claims (@context, type, etc.) are included in vp claim.
     *   There was a discussion in the chat in favor of a separate token approace that lives separate from the OIDC claims and contexts. Justin wrote that the ID Token should be about the authentication event, more than anything
        *   Mike said that the problem with the separate token approach is it probably means you're inventing new response type values, which isn't an extension point that most of the existing OAuth and OIDC libraries actually have, Whereas all the libraries enable extensions via adding claims - it's a more straightforward way of integration.
        *   Vittorio said that proposed new claim is not the same as any other new claim. If the entire reason you are asking for an ID token is to get that claim, that's changing the semantics - you are loading an existing primitive for a different out come.
        *   In that case, re-using existing logic may be disastrous since something that looks like an old stuff actually has different semantics. He said he is worried about the code that is being used already, that now can parse new artifacts and draw conclusions that are not what we wanted to do to draw.
        *   Justin said that new response_type may not be required. The utility of the response type is to allow clients to signal that they're requesting the different parts of the response separately from each other and in specific combinations. Including VCs in OIDC is different - it is specifically additive and can be defined as being returned in a specific slot. we are going towards claims query language.
        *   it's just another data artifact that, if we don't want to, or need to get overly specific about exactly how, and when we want to give clients, options, about how and where it comes back, then we don't have to.
        *   Torsten asked if it would make sense for a client to ask for a set of claims and do not care whether they can be provided as an ID token or as VCO.
        *   Mike said that the more choices you give implementations, the less interoperable they're going to be. Standards is exactly the process of making choices so that people interoperate. which is why existing mechanisms should be used.
     *   Currently there are three options - separate tokens, credential sources (library), and custom claim names. The group agreed to take a deeper look at each and continue the conversation on the ML, IIW and future calls.
  *   Update on Portable Identifiers draft (if any)
     *   Tobias said that he added use-cases and asked for feedback: https://mattrglobal.github.io/oidc-portable-identities/#name-usecases
     *   It is an alternative type of subject identifier. Currently end user subject identifier is a product of hte provider, the iss claim and the subject. cryptographically verifiable identifiers would be used to redefine the relationship btw the end user and the provider.
     *   Kristina noted that there are two components emerging - Credential exchange (VCO in OIDC) and authentication using cryptographically verifiable subject identifiers.
  *   #1215 - SIOP requires user consent<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%2F1215%2Fsiop-requires-user-consent&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C3a64af5de9524b4ea87b08d8fed02d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539517352110609%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yuqUgsUfuKNp28EDDpLjHjAADJfX3LKdVgFvr59AJqg%3D&reserved=0>
  *    #1217 - Require JAR in SIOP to strongly ID the Relying Party<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbitbucket.org%2Fopenid%2Fconnect%2Fissues%2F1217%2Frequire-jar-in-siop-to-strongly-id-the&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C3a64af5de9524b4ea87b08d8fed02d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539517352100649%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dpkiq5sbpg5gsHF%2BSVNQlBq9hSSP3S9HMNYA7gaTyf0%3D&reserved=0> - related to the last week's trust model of SIOP discussion
     *   Tom Jones said that consent in SIOP has to be required, and suggested using JAR so that the user knows about hte client
     *   Torsten asked what would you learn about client by signing request...
     *   Jeremie said that in the context of a trust framework, it can make sense because the holder SW can verify against that trust framework. but without a trust framework, no way for a holder SW to display anything useful to a user. The client might need to present their VP first too.
     *   Tom said that if TLS is used, domain name with a lock can be showed ot a user even without a framework.
     *   Tom agreed to provide more details to help WG better understand the proposal
  *   We ran out of time to discuss userInfo in SIOP
Next call is 27th April Atlantic time (7am PST, 5pm CET, 0AM JST)


差出人: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> が Torsten Lodderstedt via Openid-specs-ab <openid-specs-ab at lists.openid.net> の代理で送信
送信日時: 2021年4月14日 8:01
宛先: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
CC: Torsten Lodderstedt <torsten at lodderstedt.net>
件名: [Openid-specs-ab] OpenID Connect for W3C Verifiable Credential Objects

Hi all,

as discussed in the SIOP Special Topic Call, I would like to share with the group the link to our draft and the PRs/branches containing the alternative representations for VPs & VCs.

The current revision of the draft can be found at https://github.com/awoie/vp-token-spec<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fawoie%2Fvp-token-spec&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C82300f294e18488d347308d8fed061d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539518468934540%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gHC2NGojYFW348vyKQDc%2FzGK48%2B1fSkmzqgWxXgnjec%3D&reserved=0>. It uses VP Tokens as separate artifact + ID Tokens as Verifiable Presentations.

In the context of the ongoing discussion regarding the best way to represent, we created two PRs describing further alternatives in detail:

- vp_jwt/vp_ldp/vc_jwt/vc_ldp Claims (https://github.com/awoie/vp-token-spec/pull/20<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fawoie%2Fvp-token-spec%2Fpull%2F20&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C82300f294e18488d347308d8fed061d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539518468944494%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5KyjcvxVHzFo%2F2CJF4CgCp4wdSNG0qYQi5rcL6Ge1VU%3D&reserved=0>)
        - https://github.com/Sakurann/vp-token-spec<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSakurann%2Fvp-token-spec&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C82300f294e18488d347308d8fed061d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539518468944494%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zvTS%2F30zA5vuL0%2BVDlyCuE4ns46R6Bl%2F8YUM4stNhwk%3D&reserved=0>

- Aggregated & Distributed Claims (https://github.com/awoie/vp-token-spec/pull/23<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fawoie%2Fvp-token-spec%2Fpull%2F23&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C82300f294e18488d347308d8fed061d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539518468954450%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vvL%2Fu2DfVYnqmuOf1%2B9VxltnBgmwh7%2FOiA%2BypmQI6OA%3D&reserved=0>)
        - https://github.com/awoie/vp-token-spec/tree/adc<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fawoie%2Fvp-token-spec%2Ftree%2Fadc&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C82300f294e18488d347308d8fed061d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539518468954450%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8AbJw85Hr%2B3HGu7eCN6ClAKWN%2B1iKF8V78R0kVNfR6s%3D&reserved=0>

Look forward to getting your feedback. We would like to work towards the WG adopting our draft.

I also added the deck I have shown in the call.

best regards,

Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210427/cd88d869/attachment-0001.html>

More information about the Openid-specs-ab mailing list