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

From: Jim Schaad <[email-masked]>
Date: Tue, 14 Feb 2017 14:35:35 -0800

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.

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.

>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?

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?

Jim

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 15 Feb 2017 09:41:20 +0100

> explicit or implicit and thus identifying things just by scope would not

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).

> looking at three different entities that need to be able to understand how

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.

> or even a group name depending on the application being processed.  Is this

That is also my interpretation.

> 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 +46(0)70-349 92 51