[Openid-specs-ab] SIOP Special call notes 13-April-21 Fw: OpenID Connect for W3C Verifiable Credential Objects

Kristina Yasuda Kristina.Yasuda at microsoft.com
Wed Apr 14 04:27:01 UTC 2021 

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).

Best,
Kristina
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)

Best,
Kristina


________________________________
差出人: 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,
Torsten.

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C82300f294e18488d347308d8fed061d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637539518468954450%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Tx%2BHW6NdES%2BN6hrigf6ydfSWkqksE6tj6qkFQvomqOo%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210414/5c8ffb2f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OIDC4VCO.pdf
Type: application/pdf
Size: 849332 bytes
Desc: OIDC4VCO.pdf
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210414/5c8ffb2f/attachment.pdf>

More information about the Openid-specs-ab mailing list