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] https://www.ietf.org/mailman/listinfo/cose
