[Ace] Review for draft-ietf-ace-key-groupcomm-05

[Jim Schaad]

Here is a new review - the sooner you ask about anything that is unclear the
more likely I will remember what I was referring to.

Jim



*  In figure 4:  The CDDL is not correct.  "2*role" should be "2*role:tstr"
or role should be defined as a separate item

* Section 3.2 - The third to last paragraph is incorrect, the token should
have the expires AT not the expires IN parameter.  There is a solid
assumption that in this case there is a common idea of a wall clock between
all of the servers and there for stating a hard expiration time is more
appropriate than an expires in moment.  Additionally, tokens will generally
not include the rs_cnf even if it is in the response message and will
include a cnf for an asymmetric key.  In short, this paragraph is just plain
wrong.

* In section 3.2 - Why is the AS not allowed to return the same
authorization token to the same request assuming that things such as the
amount of time left before it expires would seem reasonable.  I am not sure
why this is a requirement let along one in this draft.   Additionally, it
says nothing about re-use of the same secret for a symmetric algorithm which
also might be something that needs to be said.

* In Section 3.3 - As an input to your "make it an array" decisions,
remember that the order of scope elements that the client gave to the AS are
not necessarily the same order as are in the token.  I think you might just
need to collapse all three arrays into a single value in the map.

* In section 3.3 - Move the data structure of sign_info to section 3.3.1

* In section 3.3 - Move the data structure description of pub_key_enc to
section 3.3.2

* In section 3.3.3 - I think you might want to rename the 'rsnonce' to be
something that is KDC specific.

* In section 4.1 - I am not sure that I like the idea of reserving
/ace-group against all comers, esp. as this is not the resource name that is
being used by the OSCORE version of the document.  You can talk to the core
people, but a better way of saying that this is a specific interface is to
defined that as a property ("if=") and register that interface name.  If
you really do mean to reserve this name against all comers then you need to
make a registration in the well-known registry as part of the IANA sections.
The last paragraph may or may not reverse the section on /ace-group.

* In section 4.1.2.1 - You cannot really reference cnonce to the framework
document as you are going to be using a different content-format and
therefore a new identifier is needed.

* In section 4.1.2.1 - See issue #60 on github about when credential
verification is needed.

* In section 4.1.2.1 - Please insert a forward pointer on 'control_path' to
a section which describes exactly what this is supposed to be doing because
it is not clear from this text.  I think it will need more than a single
paragraph to do so. 

* In section 4.1.2.1 - What happens if a 'control_path' is provided but not
supported - does that mean a bad request?

* In section 4.1.2.1 - /assigns a name NAME to the node/   is this assigning
a name to the node or to the join result?  I don't know what the node would
be but I may have missed a definition.

* In section 4.1.2.1 - Unless you have a reason for allowing floating point
for 'exp', make it integer only.  

* In section 4.1.2.1 - For control_path,  I assume that fragment is not
supported - are paramenters?  The problem is that you say "URI path" which
has a meaning.

* In section 4.1.2.1 - Mismatch between NAME and NODENAME in the text - need
to harmonize

* In Section 4.1.2.1 - I believe that the minimal content for a join request
is an empty map.  I believe that the minimal content for a join response is
an empty map.  The first makes sense as authorization comes from else where
and so can the public key if it is needed.  I am not so sure that an empty
response makes a great deal of sense for a response but it may be what you
intended.

* In Section 4.1.2.2 - I am not sure that it makes sense to return key
material to a client for which the scope permits it to join, but which has
not actually done the join process.   

* In section 4.1.3.1 - I would like to have the ability to do a fetch based
on the roles of the client associated with the public key.  That is I would
like to retrieve only those public keys associated with a requestor.

* In section 4.1.4.1 - Is there any information in the policies which is
sensitive?   Is there a reason not to return this info to everybody?

* In section 4.1.5.1 - Should this be restricted to group members?

* In section 4.1.6.1 - This is be restricted to just the correct client -
That is subscriber #2 should not be able to access subscriber #1's resource
here.

* In section 4.1.6.3 - The third paragraph is redundant as this is already
covered by the first paragraph

* In section 4.1.6.3 - The second and fourth paragraph are not making any
sense.  There is no body for a DELETE handler.

* In section 4.1.7.1 - If a public key is replaced, 

Re: [Ace] [Cwt-reg-review] [IANA #1158953] Requested review for IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

[Mike Jones]

RFC 8693 defines the “scope” JWT claim for use with OAuth 2.0, and so is 
application-specific – just like the corresponding CWT “scope” claim is 
specific to ACE OAuth.

Unless Hannes (the other Designated Expert) disagrees with my and Chuck’s 
assessment by then, I propose that we proceed with the registrations on Monday, 
registering “scope” with value 41.

   -- Mike

From: Seitz Ludwig 
Sent: Thursday, March 12, 2020 1:05 AM
To: Chuck Mortimore ; Mike Jones 

Cc: Ludwig Seitz ; drafts-expert-rev...@iana.org; 
cwt-reg-rev...@ietf.org; chuck.mortim...@visa.com; 
draft-ietf-ace-oauth-au...@ietf.org; ace@ietf.org
Subject: Re: [Cwt-reg-review] [IANA #1158953] Requested review for IANA 
registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

Hello Mike, Chuck,

Thank you for clarifying your assessment Mike, thank you Chuck for weighing in.

Mike you say: “the scope claim is specific to the ACE OAuth protocol”

This is not entirely correct, since the scope claim is defined  in  RFC 8693 
for Token Exchange, which is not an ACE protocol. Thus if any other protocol 
decides to use CWT and Token Exchange they would inherit the CWT abbreviation 
for that claim we are discussing here.
I would therefore argue that this claim abbreviation has a wider set of 
applications than just ACE.

As for the sparseness of 1 byte abbreviations: The range goes from -24 to 23. 
The CWT RFC uses 0-8 and none other are currently registered, so we have a few 
ones left.

Regards,

Ludwig


From: Chuck Mortimore 
mailto:charliemortim...@gmail.com>>
Sent: den 12 mars 2020 01:12
To: Mike Jones mailto:michael.jo...@microsoft.com>>
Cc: Ludwig Seitz mailto:ludwig_se...@gmx.de>>; 
drafts-expert-rev...@iana.org; 
cwt-reg-rev...@ietf.org; 
chuck.mortim...@visa.com; 
draft-ietf-ace-oauth-au...@ietf.org;
 ace@ietf.org
Subject: Re: [EXTERNAL] Re: [Cwt-reg-review] [IANA #1158953] Requested review 
for IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token 
Claims)

Agree with Mike's assessment.   (One caveat to that is that I'm not close 
enough to CWT to understand how scare the single byte identifiers actually are.)

On Wed, Mar 11, 2020 at 4:39 PM Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

[Adding correct e-mail addresses for Chuck, who recently joined Visa]



There are two reasons that I believe not using up one of the scarce one-byte 
claim identifiers for "scope" is appropriate:

  1.  The claim values for scopes are not short themselves.  They are sets of 
ASCII strings separated by spaces. So the percentage difference in the total 
claim representation from adding a single byte will typically be small.
  2.  The single-byte claim identifiers already registered at 
https://www.iana.org/assignments/cwt/cwt.xhtml are claims that are likely to be 
useful to diverse sets of applications, and therefore merit the short 
identifiers; whereas, the scope claim is specific to the ACE OAuth protocol and 
not applicable to diverse sets of applications.  It’s reasonable to give 
protocol-specific claim identifiers 2-byte representations.



I’d be interested to hear from the two other designated experts on my 
assessment of the situation: Hannes and Chuck.



   -- Mike



-Original Message-
From: Cwt-reg-review 
mailto:cwt-reg-review-boun...@ietf.org>> On 
Behalf Of Ludwig Seitz
Sent: Saturday, February 29, 2020 6:25 AM
To: drafts-expert-rev...@iana.org; 
cwt-reg-rev...@ietf.org
Cc: 
draft-ietf-ace-oauth-au...@ietf.org;
 ace@ietf.org
Subject: [EXTERNAL] Re: [Cwt-reg-review] [IANA #1158953] Requested review for 
IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)



On 2020-02-26 00:58, Amanda Baber via RT wrote:

> Ludwig, Hannes,

>

> Can you confirm that you can make the CBOR Web Token Claim change

> requested below?

>

> We also have Chuck Mortimore listed as an expert for this registry,

> but our message to his Salesforce address bounced.

>

> Best regards,

>

> Amanda Baber Lead IANA Services Specialist

>



I strongly disagree with the assessment that the scope claim should be pushed 
into the two-byte range.



The reason we introduced the scope claim is that an ACE RS typically does not 
have a direct connection to the AS, and is therefore unable to retrieve the 
scope of an access token from other sources than the access token itself.  I 
therefore assert that ACE access tokens would often need to contain this claim 
in order to inform the RS.

Since one of the major drivers of the ACE work has been to reduce the 
authorization overhead (otherwise we