Re: [Ace] Questions on draft-ietf-ace-oauth-authz

[Ludwig Seitz <[e-mail]>]

On 2017-02-14 23:35, Jim Schaad wrote:
> In going through and starting to map out how an implementation would work, I
> have started getting some questions.
>
> 1.  What is the difference between scope and audience, and is there an
> expected way that these values would relate to a CoAP URI?  From OAuth, I
> would have generally expected scope to identify one or more resources to be
> accessed.  However, this document requires that an audience either be
> explicit or implicit and thus identifying things just by scope would not
> work.


Scope and audience are (intentionally) defined very vaguely by OAuth 2.0.

The intention is that audience should identify the recipients of the 
access token. It is originally defined in RFC 7519 section 4.1.3.

Scope is "defined" in section 3.3. of RFC 6749. It is used in a variety 
of ways as nicely demonstrated here:
https://www.brandur.org/oauth-scope.

I mostly interpret it as identifying a set of resources and actions that 
can be performed on these resources, i.e. as a sort of capability list 
(a bit like LinkedIn uses it).

I was thinking of using some variant of the format Carsten suggested 
here: https://tools.ietf.org/html/draft-bormann-core-ace-aif-03  for 
scopes, but I've not fully evaluated the pros and cons of that idea.

I have no strong opinion on the requirement of having an explicit or 
implicit audience, I just thought it made sense the way audience and 
scope were defined (i.e. I got the impression that scope was not 
intended to cover audience).

>
> My basic expectation is that the scope and audience would normally be copied
> into the access token after doing grant evaluation.  This means that we are
> looking at three different entities that need to be able to understand how
> things fields interact.

Indeed the client and the RS need to know the meaning of the scopes and 
audiences relevant for them. The AS just needs to know which audiences 
and scopes it is allowed to grant to a client, it doesn't need to 
understand the semantics behind those values.

>
>>From my reading an audience could be anything from a host name to a full URI
> or even a group name depending on the application being processed.  Is this
> correct?

That is also my interpretation.

>
> 2.  When a cnf is sent as part of a request, are there any plans for the
> ability to do a POP as part of this being thought about?  If not, is the
> expectation that one would only offer an asymmetric key in a cnf if it had
> already be provided to the AS?
>

The use of cnf in a request by the client (to the /token endpoint) is to 
indicate a key, the client whishes to use as proof-of-possession key 
towards the RS. The AS is expected to use this cnf for the access token.

For example:

C -----{cnf="myPublicKey" ...}-----> AS
   <---CWT={cnf="myPublicKey" ...}---


/Ludwig

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