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 +46(0)70-349 92 51
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
