Good catch, fixed! I've pushed to the github, though I'll have to wait for an official revision.
The latest editor's draft is here: https://github.com/alficles/composite-claims/blob/main/composite-claims.md On Thu, Oct 31, 2024 at 5:07 PM Michael Jones <[email protected]> wrote: > 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]> 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]> > 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]> 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] > https://www.ietf.org/mailman/listinfo/cose > > > > > -- > > > > > *ORIE STEELE *Chief Technology Officer > www.transmute.industries > > <https://transmute.industries/> > >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
