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

[Jeremie Miller]

>
> 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.
>

We're in strong agreement here, and I hope I wasn't implying otherwise or
that such a relationship isn't inherent in one security container wrapping
another.

Where I'm struggling is in the instructions to the application in how to
process the double-wrapped claims.  I believe those instructions will need
to be incredibly specific to the use-case in order to detail the
relationship between both of the containers, such as how Identity Assurance
has done.

I don't believe that "vp_" and "vc_" prefixes are sufficient instructions
alone to an application developer to indicate how those claims are related
to the containing ones.  Additional specifications need to be developed to
describe exactly what those relationships mean in a given use-case context
(like SIOP or DIF's presentation exchange work).  Without that extra detail
I am worried that it's dangerous to try and specify generic claim types,
should anyone consider that enough of a standard to implement a custom
solution around and miss the important security assumptions.  For example,
such as only using the sub of the container and not the contained
credential claim, or setting a timer based on only one of the exp values.

The other part that seems premature is assuming that these additional specs
for specific use cases around requesting credentials, aggregating them,
issuing them, presenting them, etc will actually be able to use a top level
claim.  They very likely will have additional semantics that may best be
served by putting any wrapped claims in custom data structures (like
"_claims_sources":{"src1":{"JWT":"..."}} for IA).

While I am always a strong proponent of keeping things as simple as
possible and would normally be very excited about this kind of proposal,
I'm worried that it could eventually make things more complicated for the
cognitive load on app developers and on credential specification work.


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

I am too! I'm always happy to be told I'm just being too paranoid or
there's prior art/discussion I'm missing :)

Jer

-- 
_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/407e3fb3/attachment.html>