[OAUTH-WG] SD-JWT Verification strictness

[Jacob Ward]

Hello all,

Please let me know if there's a better channel to ask questions and/or
raise issues with the SD-JWT spec.

Currently as part of verification of an SD-JWT the following is stated:

*Upon receiving an SD-JWT, a Holder or a Verifier MUST ensure that *

   - *the Issuer-signed JWT is valid, i.e., it is signed by the Issuer and
   the signature is valid, and*
   - *all Disclosures are correct, i.e., their digests are referenced in
   the Issuer-signed JWT.*

As highlighted I have a question about this second bullet point. Can I ask
why the Disclosures must be referenced in the Issuer-signed JWT and not
simply ignored if they do not exist in the JWT? There doesn't appear to be
a security benefit to simply halt and to not verify what could otherwise be
a valid SD-JWT, as the unbound Disclosures would never be processed as part
of the SD-JWT verification anyway.

Apologies if this is something that has previously been discussed.

Jacob Ward
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Clarification on SD-JWT verification

[Jacob Ward]

Hello again,

On a similar note to my previous email, could I get some clarity on a step
in the SD-JWT verification process?



*4. If any digests were found more than once in the previous step, the
SD-JWT MUST be rejected.*
Step 4 in Section 6.1 (as shown above) could have multiple meanings in my
opinion:
- The digest was found multiple times (for example in an "_sd" array and as
an array element).
- More than one Disclosure have the same digest.

On first reading of this I assumed that this step only covered the first of
those two cases, but it has been pointed out to me by a colleague that it
could cover both. If it is the case that both cases are covered by this
step, then I think it would be helpful to clarify this in the text.

Cheers,

Jacob
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT Verification strictness

[Jacob Ward]

Hi Daniel,

Thanks for the response, that makes total sense.

Jacob

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Type Metadata for SD-JWT VC

[Jacob Ward]

Hi Daniel,

I'm not sure anyone has published a draft yet, but given that there is a
draft for SD-CWT I wouldn't be surprised if SD-CWT VC appears at some
point. With that in mind, has there been any discussion on having an
encoding-agnostic specification of this metadata, rather than JSON specific?

Thanks, Jacob

On Wed, Apr 3, 2024 at 8:22 AM Daniel Fett  wrote:

> Hi all,
>
> as discussed during IETF 119, we would like to introduce what we call Type
> Metadata to SD-JWT VC.
>
> For a bit of context, the intention is to provide a mechanism to provide
> information about credential types (e.g., a JSON schema, display/rendering
> information, a name and description to be used by developers, etc.). Type
> Metadata can be organized in a hierarchical structure using "extends"
> relationships.
>
> The need for such a mechanism developed from discussions around the 'vct'
> (Verifiable Credentials Type) identifier
>  in SD-JWT VC and
> again in the context of the EUDI Wallet
> .
>
> I drafted a first tentative design in this specification
> 
> and we now want to revisit that and start moving pieces of that over to
> SD-JWT VC.
>
> The first PR 
> introduces the basic Type Metadata structures including the extension and
> integrity protection mechanisms. It lacks many of the features we would
> like to see in an MVP, so we plan to release a new draft only after
> introducing a few more features
>  in follow-on PRs.
>
> We would like to invite you to review the PR and let us know if there is
> any feedback! I also plan to discuss this in more detail at an unconference
> session at the OAuth Security Workshop.
>
> -Daniel, Brian, Oliver
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth