On 07/02/2019 17:12, Hannes Tschofenig wrote:
Hi Ludwig,
What I understood from the feed-back is that using a parameter
called "aud" in a request to the token endpoint would be
interpreted as a restriction on the audience of authorization
servers that are addressed by this request.
I am not
For better or worse there is a long and winding road that has led to where
we are now with these parameters. And there has been plenty of
misunderstanding, miscommunication, dysfunction, questionable decisions,
and general SDO process along the way that/'s helped get to this point.
I've certainly
Then I think we have a bigger issue:(
To me the point of the "resource-indicators" spec is to define semantics
around how a client can request that tokens be "constrained" in where
they can be used. If it is not going to define the actual 'resource'
parameter and rather use the registered
Hi George,
The IANA registry does not indicate in what context these parameters are
supposed to be used. To me it feels totally normal to use the audience
parameter instead of the resource parameter when I have a logical name.
Stuffing everything into a URI is possible but in certain scenarios
Hi Ludwig,
> What I understood from the feed-back is that using a parameter called "aud"
> in a request to the token endpoint would be interpreted as a restriction on
> the audience of authorization servers that are addressed by this request.
I am not talking about a parameter called 'aud'.
This is true... however, to my knowledge there is no support for this
parameter outside of the token-exchange spec. Just because it is
documented as an OAuth parameter I don't consider it usable in other
contexts unless spec'd to do so. If we want to use 'audience' for
logical audience names
Since the authors of the token exchange draft have asked IANA for an early
registration of the parameters I get the impression that the question is more “
does the resource indicator spec need to define the resource parameter (or
rather reference the resource and audience parameters from the
+1 for rationalizing this! :)
On 2/7/19 10:24 AM, Hannes Tschofenig wrote:
Hi all,
after re-reading token exchange, the resource indicator, and the
ace-oauth-params drafts I am wondering whether it is really necessary
to have different functionality in ACE vs. in OAuth for basic parameters.
To add to that,
3. If a device uses HTTP Token Exchange it can use both resource and
audience parameters.
With the recent discussion and changes to the language in the resource
indicators draft, does the token exchange spec need a unique audience
parameter?
S pozdravem,
*Filip Skokan*
On Thu,
On 07/02/2019 16:24, Hannes Tschofenig wrote:
Hi all,
after re-reading token exchange, the resource indicator, and the
ace-oauth-params drafts I am wondering whether it is really necessary to
have different functionality in ACE vs. in OAuth for basic parameters.
Imagine I use an
Hi Ludwig,
the issue is that folks in the OAuth group have defined two parameters, namely
resource (for URIs) and audience (for logical names), and in ACE there is only
one doing both.
To me this appears to be sub-optimal to have different ways to accomplish the
same goal just based on the
On 07/02/2019 16:15, Hannes Tschofenig wrote:
Hi Ludwig,
My interpretation of this is that "resource" refers to a single resource
No. Here is the text from token exchange (see last sentence):
resource
[...]
Multiple "resource" parameters may be used to indicate
that the issued
Hi all,
after re-reading token exchange, the resource indicator, and the
ace-oauth-params drafts I am wondering whether it is really necessary to have
different functionality in ACE vs. in OAuth for basic parameters.
Imagine I use an Authorization Server and I support devices that use CoAP and
Hi George,
* I believe that since the latest draft of the resource indicators spec [1]
allows for abstract identifiers, and since a URN is also a URI, you could
easily use a URN syntax to accomplish the use case outlined in your email.
After re-reading the token exchange draft I realized
Hi Ludwig,
> My interpretation of this is that "resource" refers to a single resource
No. Here is the text from token exchange (see last sentence):
resource
OPTIONAL. Indicates the location of the target service or
resource where the client intends to use the requested security
Hi ACE co-chairs,
With the new est-coaps draft version-8, a new content-format was added
to the already existing list.
Given the advanced interop testing we ask you to start the process for a
preliminary registration of
this additional content-format.
copied from the text:
16 matches
Mail list logo
