Re: [Ace] WGLC for draft-ietf-ace-authz

[Ludwig Seitz <[e-mail]>]

On 22/10/2018 21:09, Jim Schaad wrote:

> 
> * Registries -  I am wondering if we should think about re-writing a couple
> of the registries.  As things stand it appears that the application/ace+cbor
> content type is being used in 5 or 6 places.  It might make more sense to
> have a registry for all of the CBOR abbreviations that are being used in a
> single table and have multiple columns for each of the different places were
> the content format is being used.  This would make it easier to keep
> everything constant and can make re-use of integer values easier to see.
> 

Yes in the light of the ensuing discussion with Mike, Carsten and Olaf 
it is clear that the whole registry process needs a second (third, n-th) 
go-over.

I'd very much like to have all abbreviations in a single table, however 
some of them are in the new draft-ietf-ace-oauth-params, so I'm not sure 
on where to do the table, since I'd like to have the parameters from 
there in it.


> * Comments on protection of CWT/Token:  I am wondering if there needs to be
> any comments on how a CWT is going to be protected.  While it is ok to use
> either a symmetric key or a direct key agreement operation for a single
> recipient without forcing a signature operation to occur.  If the token is
> going to be targeted a single audience hosted on multiple RSs then a
> signature operation would be required for the purposes of authentication.
> 

In the light of your and Steffi's comments, this seems to merit a 
section in the security considerations.

> * I am not sure where this issue should be raised so I am putting it here.
> Both of the profiles have as their last security consideration a statement
> that the use of multiple access tokens is a bad idea.  Both of them also
> devote a large section of text to how to deal with multiple access tokens as
> does this document.  More methods of having multiple access tokens seem to
> be coming down the path from the OAuth group.  This appears to be a distinct
> contradiction within the set of documents that should be resolved.
> 

I'd like to have the view of our OAuth experts here: How is OAuth 
typically used, when a client needs to get more permissions than 
initially granted?
Is the old token invalidated and a new token issued, or is there 
something like "add-on" scopes in additional tokens?

Given the amount of trouble the handling of multiple tokens for one 
client-RS pair can raise, I'm not disinclined to forbid them or at least 
recommend against their use. However with audiences possibly addressing 
overlapping sets of RSs this might be more difficult than it looks.



/Ludwig


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