I also agree that “resource” should be a specific
network-addressable URL whereas a separate audience parameter
(like “aud” in JWTs) can refer to one or more logical resources.
They are different, if related, things.
Note that the ACE WG is proposing to register a logical audience
parameter “req_aud” in
https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 -
partly based on feedback from OAuth WG members. This is a
general OAuth parameter, which any OAuth deployment will be able
to use.
I therefore believe that no changes are needed to
draft-ietf-oauth-resource-indicators, as the logical audience
work is already happening in another draft.
-- Mike
*From:* OAuth <oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>> *On Behalf Of * John Bradley
*Sent:* Saturday, January 19, 2019 9:01 AM
*To:* Brian Campbell <bcampb...@pingidentity.com
<mailto:bcampb...@pingidentity.com>>
*Cc:* Vittorio Bertocci <Vittorio=40auth0....@dmarc.ietf.org
<mailto:Vittorio=40auth0....@dmarc.ietf.org>>; IETF oauth WG
<oauth@ietf.org <mailto:oauth@ietf.org>>
*Subject:* Re: [OAUTH-WG] Shepherd write-up for
draft-ietf-oauth-resource-indicators-01
We need to decide if we want to make a change.
For security we are location centric.
I prefer to keep resource location separate from logical audience
that can be a scope or other parameter.
If becomes harder for people to use the parameter correctly if we
are too flexible.
I would rather have a separate logical audience parameter if we
think we want one.
John B.
On Sat, Jan 19, 2019, 11:41 AM Brian Campbell
<bcampb...@pingidentity.com <mailto:bcampb...@pingidentity.com>
wrote:
No apology needed, Rifaat. And I apologize if what I said
came off the wrong way. I was just trying to make light of
the situation.. And I agree that we should not be hamstrung
by the process and there are times when it makes sense to be
flexible with things.
On Fri, Jan 18, 2019 at 6:22 PM Rifaat Shekh-Yusef
<rifaat.i...@gmail.com <mailto:rifaat.i...@gmail.com>> wrote:
Sorry Brian, I was not clear with my statement.
I meant to say that we should not allow the process to
prevent the WG from producing a quality document without
issues, assuming there is an issue in the first place.
Ideally we want to get these identified during the WGLC,
but things happen and sometimes the WG misses something.
I hear you and agree that this make things difficult for
authors. We will make sure that this does not become the
norm, and we will try to stick to the process as much as
possible.
Regards,
Rifaat
On Fri, Jan 18, 2019 at 5:35 PM Brian Campbell
<bcampb...@pingidentity.com
<mailto:bcampb...@pingidentity.com>> wrote:
Thanks Rifaat. Process is as process does, right? I
do kinda want to grumble about WGCL having passed
already but that's mostly because replying to these
kinds of threads is hard for me and I'll just get
over it...
As far as I understand things, the security concerns
come into play when the client is being told the by
the resource how to identity the resource like is
described in
https://tools.ietf.org/html/draft-ietf-oauth-distributed-01
and using the actual location in that context ,along
with some other checks prescribed in that draft,
prevents the kind of issues John described earlier in
the thread.
In cases where the client knows the resource a priori
or out-of-band or configured or whatever, I don't
think the same security concerns arise. And using
such a known value, be it an actual location or
logical representation, would be okay.
The resource-indicators draft is admittedly somewhat
location-centric in how it talks about the value of
the 'resource' parameter. But ultimately it defines
it as an absolute URI that indicates the location of
the target service or resource where access is being
requested. A location can be varying shades of
abstract and I'd say that using a URI as 'resource'
parameter value that's a logical identifier that
points to some resource is well within the bounds of
the draft.
So maybe the draft is okay as is?
Or perhaps that's too much to be left as an exerciser
to the reader? And some text should be added and/or
adjusted so the resource-indicators draft would be a
little more open/clear about the parameter value
potentially being more of a logical or abstract
identifier and not necessarily a network addressable URL?
On Fri, Jan 18, 2019 at 1:18 PM Rifaat Shekh-Yusef
<rifaat.i...@gmail.com
<mailto:rifaat.i...@gmail.com>> wrote:
I wouldn't worry too much about the process.
If it makes sense to update the document, then
feel free to do that.
Regards,
Rifaat
On Fri, Jan 18, 2019 at 3:08 PM John Bradley
<ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>> wrote:
Yes the logical resource can be provided by
"scope"
Some implementations like Ping and Auth0 have
been adding another parameter "aud" to
identify the logical resource and then using
scopes to define permissions to the resource.
Fortunately, we are using a
different parameter name so not stepping on
that..
We could go back and try to add text
explaining the difference, but we are quite
late in the process.
I agree that a logical resource parameter may
be helpful, but perhaps it should be a
separate draft.
John B.
On Fri, Jan 18, 2019 at 4:38 PM Richard
Backman, Annabelle <richa...@amazon.com
<mailto:richa...@amazon.com>> wrote:
Doesn’t the “scope” parameter already
provide a means of specifying a logical
identifier?
--
Annabelle Richard Backman
AWS Identity
*From: *OAuth <oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>> on
behalf of Vittorio Bertocci
<Vittorio=40auth0....@dmarc.ietf.org
<mailto:40auth0.....@dmarc.ietf.org>>
*Date: *Friday, January 18, 2019 at 5:47 AM
*To: *John Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>>
*Cc: *IETF oauth WG <oauth@ietf.org
<mailto:oauth@ietf.org>>
*Subject: *Re: [OAUTH-WG] Shepherd
write-up for
draft-ietf-oauth-resource-indicators-01
Thanks John for the background.
I agree that from the client validation
PoV, having an identifier corresponding
to a location makes things more solid.
That said: the use of logical identifiers
is widespread, as it has significant
practical advantages (think of services
that assign generated hosting URLs only
at deployment time, or services that are
somehow grouped under the same logical
audience across
regions/environment/deployments). People
won't stop using logical identifiers,
because they often have no alternative
(generating new audiences on the fly at
the AS every time you do a deployment and
get assigned a new URL can be
unfeasible). Leaving a widely used
approach as exercise to the reader seems
a disservice to the community, given that
this might lead to vendors (for example
Microsoft and Auth0) keeping their own
proprietary parameters, or developers
misusing the ones in place; would make it
hard for SDK developers to provide
libraries that work out of the box with
different ASes; and so on.
Would it be feasible to add such
parameter directly in this spec? That
would eliminate the interop issues, and
also gives us a chance to fully warn
people about the security shortcomings of
choosing that approach.
On Thu, Jan 17, 2019 at 4:32 PM John
Bradley <ve7...@ve7jtb.com
<mailto:ve7...@ve7jtb.com>> wrote:
We have discussed this.
Audiences can certainly be logical
identifiers.
This however is a more specific
location. The AS is free to map the
location into some abstract audience
in the AT.
From a security point of view once
the client starts asking for logical
resources it can be tricked into
asking for the wrong one as a bad
resource can always lie about what
logical resource it is.
If we were to change it, how a client
would validate it becomes challenging
to impossible.
The AS is free to do whatever mapping
of locations to identifiers it needs
for access tokens.
Some implementations may want to keep
additional parameters like logical
audience, but that should be separate
from resource.
John B.
On 1/17/2019 9:56 AM, Rifaat
Shekh-Yusef wrote:
Hi Vittorio,
The text you quoted is copied
form the abstract of the draft
itself.
*Authors,*
Should the draft be updated to
cover the logical identifier case?
Regards,
Rifaat
On Thu, Jan 17, 2019 at 8:19 AM
Vittorio Bertocci
<vitto...@auth0.com
<mailto:vitto...@auth0.com>> wrote:
Hi Rifaat,
one detail. The tech summary says
An extension to the OAuth 2.0
Authorization Framework
defining request
parameters that enable a
client to explicitly signal
to an authorization server
about the *location* of the
protected resource(s) to
which it is requesting
access.
But at least in the Microsoft
implementation, the resource
identifier doesn't /have/ to
be a network addressable URL
(and if it is, it doesn't
strictly need to match the
actual resource location). It
can be a logical identifier,
tho using the actual resource
location there has benefits
(domain ownership check,
prevention of token
forwarding etc).
Same for Auth0, the audience
parameter is a logical
identifier rather than a
location.
On Wed, Jan 16, 2019 at 6:32
PM Rifaat Shekh-Yusef
<rifaat.i...@gmail.com
<mailto:rifaat.i...@gmail.com>>
wrote:
All,
The following is the
first shepherd write-up
for
the
draft-ietf-oauth-resource-indicators-01
document.
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/shepherdwriteup/
Please, take a look and
let me know if I missed
anything.
Regards,
Rifaat
_______________________________________________
OAuth mailing list
OAuth@ietf.org
<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf..org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
*/CONFIDENTIALITY NOTICE: This email may contain
confidential and privileged material for the sole use
of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly
prohibited. If you have received this communication
in error, please notify the sender immediately by
e-mail and delete the message and any file
attachments from your computer. Thank you./*
*/CONFIDENTIALITY NOTICE: This email may contain confidential
and privileged material for the sole use of the intended
recipient(s). Any review, use, distribution or disclosure by
others is strictly prohibited.. If you have received this
communication in error, please notify the sender immediately
by e-mail and delete the message and any file attachments
from your computer. Thank you./*
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
