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