There appears to be a duplicate claim registration requested. In:
Claim Name: and Claim Description: Logical AND JWT Claim Name: N/A
Claim Key: TBD (greater than 285) Claim Value Type(s): array Change
Controller: IETF
Claim Name: enc Claim Description: Logical AND JWT Claim Name: N/A
Claim Key: TBD (greater than 285) Claim Value Type(s): array Change
Controller: IETF
Both the claims “and” and “enc” have the same description.
-- Mike
From: Chris Lemmons <[email protected]>
Sent: Thursday, October 24, 2024 1:33 PM
To: [email protected]
Subject: [COSE] Re: Interest for draft-lemmons-composite-claims-01
It's been a while, but I've updated the Composite Claims document based on much
of the feedback I've received from this group. I went ahead and renamed it to
include the group name so it's easier for folks to notice that it's here.
https://datatracker.ietf.org/doc/draft-lemmons-cose-composite-claims/00/
The new draft has CDDL to more clearly communicate the formats as well as
significantly expanded examples demonstrating how they can be used.
On Fri, Oct 27, 2023 at 3:21 AM Chris Lemmons
<[email protected]<mailto:[email protected]>> wrote:
Yup! Those are both relevant and useful, though they don't support exactly the
same use cases.
In particular, SD-CWTs don't quite work for the bearer tokens I'd like to use
because I'd like the _issuer_ to deny access to the non-disclosed claim
_values_. The bearer needs to not have to modify their token. Additionally, I
need the relying party to be able to read the claim key so they can tell if the
stuff inside the envelope might be a problem. A relying party that doesn't care
what the identity of the bearer is might accept a token that has an envelope
with an identity claim inside. A relying party that does care might reject the
request if they can't open the envelope to verify the identity.
I hadn't seen the JPTs before, but the Design Considerations section does a
good job of highlighting where these approaches differ. For example, conveying
claim values from issuer to relier without revealing them to the bearer is one
of the goals of this envelope and that should be called out because it has both
security and privacy implications.
On Thu, Oct 26, 2023 at 3:27 PM Orie Steele
<[email protected]<mailto:[email protected]>> wrote:
Hey Chris!
Glad to see the draft : )
I am very interested in this, and look forward to hearing from others,
regarding the approach in the draft.
Because this draft comments on both signatures and encryptions in relation to
CWT claims I wanted to share 2 other related threads for folks who are
interested in the general properties of disclosure and linkability:
1. https://datatracker.ietf.org/doc/draft-prorock-cose-sd-cwt/ (like
https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ but
for CWT).
2. https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-proof-token-02 (
has selective disclosure and unlinkability capabilities, which you might be
interested in leveraging, alongside or instead the logical operators)
Regards,
OS
On Thu, Oct 26, 2023 at 4:00 PM Chris Lemmons
<[email protected]<mailto:[email protected]>> wrote:
Link up front: https://datatracker.ietf.org/doc/draft-lemmons-composite-claims/
This is new work I'd like to see if there is interest in. I have a
specific need for these particular CWT claims, but they're completely
general and not specific to my use-case. I have a draft linked above,
but the core concept is that sometimes, you need to compose claims
with boolean logic or encrypt the claim contents.
For example:
I am Chris or David, but I decline to tell you which. If that's ok
with you, you can accept my credential.
Or to encrypt a claim, consider:
I have a bearer token with a claim about who I am, but it is
encrypted, and a claim for what I am authorized to access, which is in
the clear. A processor that only cares about the latter doesn't need a
decryption key for the former, allowing the token to be processed by
an entity without revealing the identity to the processor.
And lastly, it defines a crit claim for cwts, which doesn't exist yet.
I think this document should be very simple and direct in scope. It
shouldn't need to go into detail about all the possible way these
elements can be composed. It just needs to register the compositions
and explain how they can be safely used and how they must be
processed.
What are your thoughts? Would it be worth a few minutes of agenda at
118 to explain and answer questions, if we have time available?
_______________________________________________
COSE mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/cose
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries<http://www.transmute.industries/>
[https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
