[only posting to OAuth list] Hi William,
thanks for your quick review comments. On 11/13/2015 04:19 AM, William Denniss wrote: > Regarding the draft itself, a few comments: > > 1. > Can we unify the claim registry with JWT? I'm worried about having the > same claims defined twice in CWT and JWT with possibly conflicting > meanings (and needless confusion even when they do match). > > Comparing > https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#section-3.1.2 > and https://tools.ietf.org/html/rfc7519#section-4.1.2 which are nearly > identical, I just don't see the value in re-defining it. > > We may add new standard claims to JWT in the future (I proposed one > <https://mailarchive.ietf.org/arch/search/?email_list=id-event&gbt=1&index=7qNUnaE9lt2LyayMnmNyWpZSIEM> > in > Yokohama on the id-event list > <https://www.ietf.org/mailman/listinfo/id-event>), it would be good if > this didn't need a separate entry in CWT too, but could just apply > directly (separately, I think you should consider this claim, as it > helps prevent tokens from being re-used in the wrong context). > For this IANA registry issue we have essentially two options: a) Single registry: JWT and CWT claims listed in the same registry b) Separate registries for JWT claims and for CWT claims. The drawback about using two registries is the additional effort in registering many, if not all, claims twice (with the potential risk to get them misaligned). The advantage is to avoid confusion when some entries are only applicable to the CWT or the JWT registry, respectively. Note that we had the same question with regard to the token introspection registry* where I argued that we should use a single registry and we ended up defining two registries in the end. In this specific case I believe there is value in using one registry only since I don't see a reason for web and smart phone apps not using the CBOR-based encoding. During the last few years I witnessed a lot of activities that aimed to reduce the message size of protocols used in the mobile space. (*): I believe that Erik should update his token introspection draft (see https://tools.ietf.org/html/draft-wahlstroem-ace-oauth-introspection-01) by registering the CWT claims to the token introspection defined registry. > 2. > Is Section 4 "Summary of CBOR major types used by defined claims" > normative > (https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#section-4)? > What is the intention of this section? I feel like it could probably be > fleshed out a bit. Maybe that section is not well motivated and should rather be placed into the IANA consideration section instead. All it does is to summarizes the CBOR-relevant information into a table. > > 3. > Add a xref to draft COSE spec in section 6 > <https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#section-6> > Add xref to RFC7519 Missing references will be fixed. Ciao Hannes > > On Thu, Nov 12, 2015 at 12:01 PM, Erik Wahlström neXus > <erik.wahlst...@nexusgroup.com <mailto:erik.wahlst...@nexusgroup.com>> > wrote: > > Hi Carsten, > > Thanks, and I agree. I’ve heard arguments for all three work groups. > > Borrowed some of your words to define the content of the draft :) > It’s it essentially a JWT, phrased in and profiled for CBOR to > address ACE needs, where OAuth needs COSE functionality, for object > security. > > I’m open for letting the AD’s move it around, but having it right > next to JWT seems right to me. Also open for the ACE WG. Feel it has > less place in COSE for the same reasons JWT is not in the JOSE WG. > > / Erik > > > > On 12 Nov 2015, at 20:45, Carsten Bormann <c...@tzi.org > <mailto:c...@tzi.org>> wrote: > > > > Hi Erik, > > > > having this draft is a good thing. > > > > One thing I'm still wondering is what WG is the best place to progress > > this. We probably don't need to spend too much time on this because, > > regardless of the WG chosen, the people in another WG can look at it. > > Still, getting this right might provide some efficiencies. > > > > What is the technical content of this draft? Is it a new token that > > OAuth needs specifically for the new COSE-based applications of OAuth? > > Is it a new token that is specifically there for addressing ACE needs? > > Or is it essentially the same substance as JWT, but phrased in and > > profiled for CBOR? > > > > Depending on the answer, CWT should be done in OAuth, ACE, or COSE. > > (I'd rather hear the answer from the authors than venture a guess > myself.) > > > > Grüße, Carsten > > > > > > > > Erik Wahlström neXus wrote: > >> Hi, > >> > >> In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was > defined > >> in the draft "Authorization for the Internet of Things using > OAuth 2.0” > >> [1]. We just broke out the CBOR Web Token into a separate draft > and the > >> new draft is submitted to the OAUTH WG. It can be found here: > >> > >> > https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token/ > >> > >> Abstract: > >> "CBOR Web Token (CWT) is a compact means of representing claims to be > >> transferred between two parties. CWT is a profile of the JSON > Web Token > >> (JWT) that is optimized for constrained devices. The claims in a > CWT are > >> encoded in the Concise Binary Object Representation (CBOR) and CBOR > >> Object Signing and Encryption (COSE) is used for added > application layer > >> security protection. A claim is a piece of information asserted > about a > >> subject and is represented as a name/value pair consisting of a claim > >> name and a claim value." > >> > >> / Erik > >> > >> > >> [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00 > >> > >> > >> _______________________________________________ > >> COSE mailing list > >> c...@ietf.org <mailto:c...@ietf.org> > >> https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > c...@ietf.org <mailto:c...@ietf.org> > https://www.ietf.org/mailman/listinfo/cose > > > > > _______________________________________________ > Ace mailing list > a...@ietf.org > https://www.ietf.org/mailman/listinfo/ace >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
