Re: [Ace] OAuth-Authz Interop

[Ludwig Seitz <[e-mail]>]

On 2018-05-08 19:40, Mike Jones wrote:
> Before any interop work is done, I suggest that it would be better to
> first address the significant CBOR number assignment issues I pointed
> out in my review on October 10, 2017 
> https://www.ietf.org/mail-archive/web/ace/current/msg02364.html, so 
> that the interop is more likely to occur using number assignments 
> that are less likely to change.  I'm repeating the most important of
>  these comments below, since it was apparently not acted upon.

I was pretty sure we went over all of your comments and replied to
you on list. We might have disagreed on some, but in that case we
clearly stated that.

Would you please specify which of your comments we have not acted upon,
so that we can rectify that?

Also I don't think the mapping of a few abbreviations should stop us 
from performing an interop.


Detailed comments below.

/Ludwig


> 5.5.5 Mapping parameters to CBOR
> 
> It looks to me like these values are intended to align with those 
> registered in the CBOR Web Token (CWT) Claims registry initially 
> populated by 
> https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08#section-9.1.2.
> > If so, the spec should make this relationship explicit.

We did address this comment.

See:
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-11#section-5.6.5
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-11#section-5.7.4

"   Note that we have aligned these abbreviations with the claim
    abbreviations defined in [I-D.ietf-ace-cbor-web-token]."

We will update that reference to the RFC in the next iteration.

> However, it would be inappropriate to use the rare single-byte CBOR 
> integer values for application-specific claim keys. I would suggest 
> that the claim identifiers for client_id through refresh_token and 
> profile start at 256 (a two-byte CBOR value) and go up from there.
> In that case, I suspect they could be successfully registered in the
> CWT Claims registry – which I think you want.  (“cnf” will already be
>  registered by draft-ietf-ace-cwt-proof-of-possession.)
> 

Those claims/request parameters are from the core OAuth 2.0 spec. I can
buy an argument that they are not relevant for constrained applications,
but they are by no means application-specific. Shall we make a case-by
case evaluation of these?

The ones used in the draft are:

aud, scope, error, error_description, error_uri, grant_type,
access_token, cnf, profile, rs_cnf.

For the Authorization Code Grant (which has been pointed out as
relevant) I would think we also need:

response_type, client_id, state, code

I would be ok with pushing the other parameters/claim keys into the
two-byte abbreviation space.


> Likewise, please search the review for all instances of the words 
> “register” and “registry” and revised the spec accordingly before any
> interop work is started.

I'm pretty sure we did cover all of your comments. Here is what we did 
(a long while ago), just for your reference:

> 5.6.5 Mapping Introspection Parameters to CBOR
> 
> As in my related comment on 5.5.5, it looks to me like these values 
> are intended to align with those registered in the CBOR Web Token 
> (CWT) Claims registry initially populated by 
> https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08#section-9.1.2.
>
 > If so, the spec should make this relationship explicit.  However, it
> would be inappropriate to use the rare single-byte CBOR integer 
> values for application-specific claim keys.  I would suggest that the
> claim identifiers for client_id through refresh_token and profile
> start at 256 (a two-byte CBOR value) and go up from there. In that
> case, I suspect they could be successfully registered in the CWT
> Claims registry – which I think you want.  (“cnf” will already be
> registered by draft-ietf-ace-cwt-proof-of-possession.)
> 

Done, see above


> 8.1 OAuth Introspection Response Parameter Registration
> 
> Every place an IANA registration currently says “this document”, 
> please change it to “Section x.y.z of this document” (using the 
> appropriate <ref target=”x.y.z”/> tag for the section that defines 
> the value.
> 
> 
We followed the example of other documents that also lacked the specific
section references. If you think this is important we can make that change.

> 
> 8.1 OAuth Introspection Response Parameter Registration
> 
> “aud” is already registered at 
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response.

In this draft aud is also used in the authorization token request. The
registry entry you point at is from the OAuth Token Introspection
Response list we want to have that parameter in the OAuth Parameters
list as well.

> 
> 8.4 Token Type Mappings
> 
> The name “Token Type Mappings” registry is too generic.  Please 
> change it to “OAuth Token Type CBOR Mappings” or something similar.
Done, this is now 8.5



> 8.4.1  Registration Template
> 
> As was pointed out in comments on earlier versions of the CWT spec, 
> the range 1 to 65536 makes no sense.  Please consider using the same
>  treatment of value ranges as CWT does (which themselves derived from
>  the COSE usage of value ranges).  Do this consistently every place 
> that “1 to 65536” occurs in the spec.
This seems to have been missed. I will go over that again.


> 8.5 CBOR Web Token Claims
> 
> “cnf” is already being registered by
> draft-ietf-ace-cwt-proof-of-possession.
> 
It is being registered as a authorization token claim. We are
registering it in the OAuth Parameters and OAuth Token Introspection
Response.


> 8.6 ACE Profile Registry
> 
> The name “ACE Profile Registry” registry is too generic.  Please
> change it to “ACE OAuth Profile Registry” or something similar.
> 
Done


> 8.7 OAuth Parameter Mappings Registry
> 
> The name “OAuth Parameter Mappings” registry is too generic.  Please
> change it to “OAuth CBOR Parameter Mappings” or something similar.
Done



> 8.7.2 Initial Registry Contents
> 
> Per my earlier comments, these values should actually reference the
> CWT Claims registry and application-specific values such as
> “client_id”, etc. should not use the scarce single-byte value range.
See discussion above


> 8.8.1 Registration Template
> 
> Registrations for the Introspection Endpoint CBOR Mappings registry
> should contain a field that lists the corresponding value registered
> in the OAuth Token Introspection Response registry at
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response.
That would be the "Name" field. It currently refers to the OAuth 
Parameters registry, would you prefer that we refer to the specific 
section "OAuth Token Introspection Response"?

> 
> 8.10 CWT Confirmation Methods Registry
> 
> Delete this section, as it has been moved to
> draft-ietf-ace-cwt-proof-of-possession.
> 
Done

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone [phone]