[Openid-specs-ab] [EXTERNAL] Re: JWT Claims for W3C Verifiable Credentials Objects

Mike Jones Michael.Jones at microsoft.com
Fri Apr 9 20:57:31 UTC 2021


I believe that Tom hit the nail on the head, here.  Having a claim in a signed JWT means that the JWT issuer is asserting the claim value pertains to the interaction at hand.  If the claim value itself (be it a JWT, an LD Proof, a SAML Token, etc.) also is cryptographically secured, processing that claim value inherently entails separately validating the cryptographic security of the claim value.  This validation is independent of the validation of the JWT itself.

Don’t trust the JWT if its cryptographic validation fails.  Don’t trust the cryptographically secured claim value if its cryptographic validation fails.

                                                       -- Mike

P.S.  I think this is a great discussion and I’m glad we’re having it!

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Tom Jones via Openid-specs-ab
Sent: Friday, April 9, 2021 12:25 PM
To: Jeremie Miller <jmiller at pingidentity.com>
Cc: Tom Jones <thomasclinganjones at gmail.com>; oliver.terbu at mesh.xyz; Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Subject: [EXTERNAL] Re: [Openid-specs-ab] JWT Claims for W3C Verifiable Credentials Objects

i can give you very specific examples of "claims" that are bundled into an id token that have an independent life of their own.

1. Claim that is an attestation about the siop wallet itself, which i believe is critical for the success of SIOP.
2. Claim about the liveness (proof of presence) of an individual, or of a webauth key , etc etc etc
3. Claim about the identity proofing of the individual, which can be a mobile driver's license or a statement of an existing proofed identity at (e.g.) a bank or a primary care physician.

I find this idea to be difficult, as Jeremie noted, but essential for the future of anything like OIDC.

Be the change you want to see in the world ..tom


On Fri, Apr 9, 2021 at 11:58 AM Jeremie Miller <jmiller at pingidentity.com<mailto:jmiller at pingidentity.com>> wrote:
I'm having a difficult time understanding the security implications with these proposed claims.

When I am writing an application that processes a JWT that has been validated by my JOSE library, I then process the contained claims in the security context that was just validated (by the issuer, for an audience, about a subject, etc).  The moment I encounter _any_ claim that is itself _another_ clearly identified and self-contained security context, there needs to be extremely specific rules about how those two different contexts relate to each other.

If the new context is from a different issuer, is this an aggregation? Is there an implication from the parent issuer having signed it providing any assurance or binding? See the Identity Assurance draft for all the extra framework metadata that is required in that particular case: https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html

What if the new claim has a longer expiration? Which is valid? Or for a different subject, are they linked? It's a claim containing new claims, and I struggle to imagine all of the ways the two might intersect and how I as the application developer could properly evaluate that without very specific guidance and extra information from a spec.

Just adding standard claim names to support this pattern seems like it is dismissing the very important security complexity of mixing claims with two potentially drastically different envelopes.  Leaving that up to future spec writers to solve feels like handing off an armed grenade.

Without doing the work like Identity Assurance to clearly define the relationship between the different contexts, I'm concerned that an over-simplified inclusion can lead to over-simplified security assumptions.

Personally, I believe credentials are most securely returned from an issuer each as their own individual envelopes of claims, and any need to bind them together should be intrinsic to each. That would also require successful validation of all envelopes before evaluating any relationships between them, a very good thing IMO.

Jer


On Fri, Apr 9, 2021 at 11:14 AM Tom Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:
This proposal is conceptually incomplete. We need to start with the AR with new request elements, go through the consent process and finally process those 2 inputs into (inter alia) an id token.

Be the change you want to see in the world ..tom


On Thu, Apr 8, 2021 at 11:10 PM Mike Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:
I have written the first draft of the promised specification, which is both attached (to contribute it to the working group) and available online at https://openid.bitbucket.io/connect/jwt-claims-for-vc-objects-1_0.html.  The source is also checked into our bitbucket repository.

I intend this to further concrete discussions on how to interoperably include VC objects in the JWT claims world, when appropriate to the use cases.

                                                       Best wishes,
                                                       -- Mike

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210409/e79bb47f/attachment-0001.html>


More information about the Openid-specs-ab mailing list