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

Jeremie Miller jmiller at pingidentity.com
Fri Apr 9 18:58:40 UTC 2021


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> 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> 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
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
> _______________________________________________
> Openid-specs-ab mailing list
> 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/1860aa05/attachment.html>


More information about the Openid-specs-ab mailing list