[Openid-specs-digital-credentials-protocols] Minutes from 16th May 2024 DCP WG call
Orie Steele
orie at transmute.industries
Fri May 17 16:03:44 UTC 2024
Hey Brian,
On Fri, May 17, 2024 at 10:44 AM Brian Campbell <bcampbell at pingidentity.com>
wrote:
>
>
> On Fri, May 17, 2024 at 6:49 AM Orie Steele via
> Openid-specs-digital-credentials-protocols <
> openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>
>> You can use sd-jwt to produce the W3C Verifiable Presentation object:
>>
>>
>> https://www.w3.org/TR/vc-jose-cose/#securing-json-ld-verifiable-presentations-with-sd-jwt
>>
>
> What is/was the rationale for using sd-jwt to produce the W3C Verifiable
> Presentation object?
>
Conformance to the Core Data Model as described in:
https://www.w3.org/TR/2024/CRD-vc-data-model-2.0-20240513/#verifiable-presentations
> As I said over in this PR
> <https://github.com/w3c/vc-jose-cose/pull/270#issuecomment-2108832855>
> (which I'm now regretting having gotten involved in),maybe I'm not seeing
> the grand vision or something but securing a VP with SD-JWT doesn't really
> make sense to me.
>
Because VPs don't make sense? or because JWT / COSE is a better path to
secure them?
To me, it's JSON with a media type, I am not sure it needs a grand vision
beyond that.
There are important protocol considerations for VPs though, which are
described here:
https://www.w3.org/TR/2024/CRD-vc-data-model-2.0-20240513/#presentations-including-holder-claims
You can't have compatibility with this part of the W3C Technical
recommendation if you don't enable a way to secure VPs with JWT, SD-JWT,
COSE or ...
>
>
> However this requires you to present a presentation as if it were a
>> credential.
>>
>> And it creates a situation where you can have key binding in the
>> credentials and for the presentation layer.
>>
>> Our implementation supports this, but it's awkward.
>>
>> This stems from W3C defining a protocol message without having a concrete
>> protocol that is also defined, as opposed to just a data format.
>>
>> As far as I know protocols decide if they want to support W3C
>> presentations or just W3C credentials... And oidc has so far, never
>> supported W3C presentations.
>>
>
> Again, maybe I'm not seeing the grand vision or something but that doesn't
> sound right to me*. I would agree though that the protocol and message
> layering in all this is sometimes confused and often confusing.
>
> * these seem like they are W3C Verifiable Presentations...
>
> https://openid.net/specs/openid-4-verifiable-presentations-1_0-20.html#appendix-A.1.1.3-5
>
> https://openid.net/specs/openid-4-verifiable-presentations-1_0-20.html#appendix-A.1.2.3-5
>
This is not a W3C VP:
{
"iss": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
"aud": "https://client.example.org/cb",
"nbf": 1541493724,
"iat": 1541493724,
"exp": 1573029723,
"nonce": "n-0S6_WzA2Mj",
"vp": {
"@context": [
"https://www.w3.org/2018/credentials/v1"
],
"type": [
"VerifiablePresentation"
],
"verifiableCredential": [
"eyJhb...ssw5c"
]
}
}
it's an object that contains a claim called "vp" which might contain a
JSON-LD VP, but it's malformed, because of the structure of
"verifiableCredential".
See:
https://www.w3.org/TR/2024/CRD-vc-data-model-2.0-20240513/#enveloped-verifiable-credentials
Also, per
https://w3c.github.io/vc-jose-cose/#securing-verifiable-credentials
The JWT Claim Names vc and vp MUST NOT be present in any JWT Claims Set.
>
>
>>
>> On Fri, May 17, 2024, 2:20 AM Jan Vereecken via
>> Openid-specs-digital-credentials-protocols <
>> openid-specs-digital-credentials-protocols at lists.openid.net> wrote:
>>
>>> Hi Joseph and other members,
>>>
>>>
>>>
>>> Regarding
>>>
>>>
>>>
>>> > Two people asked about how to return multiple credentials fulfilling
>>> the same single requirement; that hadn’t come up before and we probably
>>> need a way to express if the verifier wants all the matches or just one -
>>> new issue to be opened for that.
>>>
>>>
>>>
>>> I just want to qualify my question further.
>>>
>>>
>>>
>>> I was thinking more of the case where a single presentation is answering
>>> multiple credentials requests.
>>>
>>>
>>>
>>> Specifically W3C VCDM enables presentation of multiple credentials,
>>> bound to the same identifier, in a single presentation object. In contrast,
>>> to my knowledge, SD-JWT VC does not have this.
>>>
>>>
>>>
>>> For the example, let’s conceptually represent this as jwt_vp_json_a =
>>> [jwt_vc_json_1, jwt_vc_json_2], where jwt_vc_json_1 answers my_cred_1 and
>>> jwt_vc_json_2 answers my_cred_2.
>>>
>>>
>>>
>>> Does the solution envisaged then repeat the presentation object and
>>> figure out in the submission how to reference the correct credential
>>>
>>>
>>>
>>> {
>>>
>>> “my_cred_1”: “jwt_vp_json_a”,
>>>
>>> “my_cred_2”: “jwt_vp_json_a”
>>>
>>> }
>>>
>>>
>>>
>>> Or, do we require multiple presentation object, each one replying to
>>> exactly one of the request
>>>
>>>
>>>
>>> jwt_vp_json_b = [jwt_vc_json_1]
>>>
>>> jwt_vp_json_c = [jwt_vc_json_2]
>>>
>>>
>>>
>>> {
>>>
>>> “my_cred_1”: “jwt_vp_json_b”,
>>>
>>> “my_cred_2”: “jwt_vp_json_c”
>>>
>>> }
>>>
>>>
>>>
>>> Or, do we allow more flexibility, but increasing complexity in response
>>> structure.
>>>
>>>
>>>
>>> [
>>>
>>> {
>>>
>>> “request”: [“my_cred_1”, “my_cred_1”],
>>>
>>> “response”: “jwt_vp_json_a”
>>>
>>> }
>>>
>>> ]
>>>
>>>
>>>
>>> Regards,
>>>
>>> Jan
>>>
>>>
>>>
>>> *From: *Openid-specs-digital-credentials-protocols <
>>> openid-specs-digital-credentials-protocols-bounces at lists.openid.net> on
>>> behalf of Joseph Heenan via Openid-specs-digital-credentials-protocols <
>>> openid-specs-digital-credentials-protocols at lists.openid.net>
>>> *Date: *Thursday, 16 May 2024 at 18:34
>>> *To: *Digital Credentials Protocols List <
>>> openid-specs-digital-credentials-protocols at lists.openid.net>
>>> *Cc: *Joseph Heenan <joseph at authlete.com>
>>> *Subject: *[Openid-specs-digital-credentials-protocols] Minutes from
>>> 16th May 2024 DCP WG call
>>>
>>>
>>>
>>> Participants:
>>>
>>>
>>>
>>> Joseph Heenan
>>>
>>> Kristina Yasuda
>>>
>>> Daniel Fett
>>>
>>> Andreea Prian
>>>
>>> Arjen van Veen
>>>
>>> Bjorn Hjelm
>>>
>>> Brian Campbell
>>>
>>> gabe
>>>
>>> Jan Vereecken
>>>
>>> Jin Wen
>>>
>>> Juba Saadi
>>>
>>> Michael Jones
>>>
>>> Oliver Terbu
>>>
>>> Pedro Felix
>>>
>>> Rajvardhan Deshmukh
>>>
>>> Ryan Galluzzo
>>>
>>> Sebastian Birckerle
>>>
>>> Sebastian Bahloul
>>>
>>> Sudesh Shetty
>>>
>>> Lukasz Jaromin
>>>
>>>
>>>
>>>
>>>
>>> *Events:*
>>>
>>>
>>>
>>> There will be a hybrid meeting with in-person participation for those at
>>> Identiverse; if you would like to attend in person please register on
>>> eventbrite:
>>>
>>>
>>>
>>>
>>> https://www.eventbrite.com/e/openid-foundation-dcp-wg-hybrid-meeting-at-identiverse-tickets-902324616217
>>>
>>>
>>>
>>> It was proposed to cancel the normal working group meetings during
>>> Identiverse & EIC and no one objected.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *VP Query Language Proposal:*
>>>
>>>
>>>
>>> Daniel shared the latest thoughts on the query language, presenting an
>>> evolution of the proposal created during IIW that meets the various
>>> requirements that were agreed by the working group, that includes some
>>> feedback from implementers that looked at the previous proposal:
>>> https://hackmd.io/1siVhjzOTWOE9ppdF_t57A?view
>>>
>>>
>>>
>>> There was some discussion over the how the logic of “and/or” requests is
>>> expressed; Daniel said the current proposal is the simplest they could come
>>> up with.
>>>
>>>
>>>
>>> Two people asked about how to return multiple credentials fulfilling the
>>> same single requirement; that hadn’t come up before and we probably need a
>>> way to express if the verifier wants all the matches or just one - new
>>> issue to be opened for that.
>>>
>>>
>>>
>>> Jan asked where both ‘format’ and the name of the format specific
>>> parameters object (e.g. “vc+sd-jwt”) are required. Daniel said that
>>> ‘format' is necessary so there is a clear place for the verifier to figure
>>> out if it supports the requested format, and then there’s also a desire to
>>> collect the format specific keys into a sub-object.
>>>
>>>
>>>
>>> Jan asked about implementations. There aren’t any yet that we’re aware
>>> of.
>>>
>>>
>>>
>>> Kristina asked if we wanted to proceed with a new query language format
>>> and if this proposal was a good way to proceed.
>>>
>>>
>>>
>>> Jan, Arjen, Brian, Michael J, Oliver, Gabe agreed it was a useful
>>> starting point. No one raised objections to using it as a starting point.
>>> Oliver wasn’t sure about the advances syntax features in example 7.
>>>
>>>
>>>
>>> Next step is to open an issue.
>>>
>>>
>>>
>>>
>>>
>>> *VP Transaction Data:*
>>>
>>>
>>>
>>> Kristina has opened 4 new issues for 4 specific points that need
>>> discussion, all tagged with the ’transaction data’ label.
>>>
>>>
>>>
>>> Issue 173: The verifier needs an easy way to check the wallet is approve
>>> what it’s requested; given the difficulties of comparing json objects
>>> having the transaction request base64url encoded in the request & response
>>> seems like the best solution right now.
>>>
>>>
>>>
>>>
>>>
>>> *VP PRs:*
>>>
>>>
>>>
>>> #175 Add text/diagram for siopv2 conditional cred req flow
>>>
>>> https://github.com/openid/OpenID4VP/pull/175 to solve
>>> https://github.com/openid/OpenID4VP/issues/86
>>>
>>>
>>>
>>> Please read and give feedback.
>>>
>>>
>>>
>>>
>>>
>>> *VCI PRs/issues:*
>>>
>>>
>>>
>>> https://github.com/openid/OpenID4VCI/pull/314
>>>
>>>
>>>
>>> Removed authorization_pending as discussed in previous meetings and
>>> notified to mailing list. No objections raised.
>>>
>>>
>>>
>>>
>>>
>>> https://github.com/openid/OpenID4VCI/pull/319
>>>
>>>
>>>
>>> As per previous working group discussions, clarify how encryption works
>>> on batch endpoint - please review.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> https://github.com/openid/OpenID4VCI/pull/321 - adds a new error code
>>> to credential endpoint for the issuer to indicate it’s denying the request
>>> - please review.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> https://github.com/openid/OpenID4VP/issues/171 - “nonce” handling
>>> should be more explicit.
>>>
>>>
>>>
>>> Kristina pointed out that SD-JWT & W3C LDP sections do contain wording;
>>> Oliver will review it and raise a PR if it can be improved.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> https://github.com/openid/OpenID4VP/issues/124 - client_id_scheme
>>> security considerations
>>>
>>>
>>>
>>> We need to come to a decision on this. The feeling when discussed at OSW
>>> seemed to be folding the client_id_scheme into the client_id in some way so
>>> the existing iss/aud fields in JWTs can be used etc. To be discussed on
>>> next week’s WG calls.
>>>
>>>
>>>
>>>
>>> --
>>> Openid-specs-digital-credentials-protocols mailing list
>>> Openid-specs-digital-credentials-protocols at lists.openid.net
>>>
>>> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
>>>
>> --
>> Openid-specs-digital-credentials-protocols mailing list
>> Openid-specs-digital-credentials-protocols at lists.openid.net
>>
>> https://lists.openid.net/mailman/listinfo/openid-specs-digital-credentials-protocols
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries
<https://transmute.industries>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/attachments/20240517/b5031965/attachment-0001.html>
More information about the Openid-specs-digital-credentials-protocols
mailing list