[Openid-specs-ab] JWT Claims for W3C Verifiable Credentials Objects
thomasclinganjones at gmail.com
Fri Apr 9 19:24:42 UTC 2021
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>
> 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:
> 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.
> 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
>>> 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
>>> Best wishes,
>>> -- Mike
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
> *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...
More information about the Openid-specs-ab