The virtual office hours in my calendar start 1/2 hour before that. If the
time has changed, can you have the meeting organizer update the calendar entry?
Thanks,
-- Mike
From: Rifaat Shekh-Yusef <[email protected]>
Sent: Thursday, January 24, 2019 12:46 PM
To: George Fletcher <[email protected]>
Cc: Vittorio Bertocci <[email protected]>; Mike Jones
<[email protected]>; [email protected]
Subject: Re: [OAUTH-WG] Shepherd write-up for
draft-ietf-oauth-resource-indicators-01
All,
This coming Monday, Jan 28 @ 12:00pm Eastern Time, we have a scheduled OAuth WG
Virtual Office meeting.
Feel free to attend the meeting to discuss this topic to try to get to a
conclusion on this.
Regards,
Rifaat
On Wed, Jan 23, 2019 at 3:00 PM George Fletcher
<[email protected]<mailto:[email protected]>> wrote:
+1
Also, I don't really like the parameter name 'req_aud' :) I'm not 100%
convinced that 'audience' and 'logical resource' are completely overlapping
concepts. We can potentially make them completely overlapping but we need text
to that effect.
I also believe that we don't have a complete solution for all deployments using
exact locations (see my previous email).
Thanks,
George
On 1/23/19 2:50 PM, Vittorio Bertocci wrote:
As mentioned below, I agree the two can be separated- but I also agree with
George on the need to be clear an easy to reference for developers.
Just adding a reference to req_aud would just raise the cyclomatic complexity
of the specs, which is already unusably high for mere mortals in the
OAuth2/OIDC family of specs.
One additional complication is that this specification is reusing a parameter
that is already used in a very large number of production systems (small
example
here<https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-oauth-code>),
and whose concrete semantic happens to be prevalently logic identifier. If the
parameter you are defining here has a different semantic, at the very least it
would seem good hygiene to rename it to avoid collision and confusion.
On Wed, Jan 23, 2019 at 11:03 AM Mike Jones
<[email protected]<mailto:[email protected]>>
wrote:
I agree with John’s logic. The physical resource and logical resource should
use different identifiers. Fortunately, we already have “resource” and
“req_aud” for these parameters. I believe we’re good to go, as-is.
-- Mike
From: OAuth <[email protected]<mailto:[email protected]>> On Behalf
Of John Bradley
Sent: Wednesday, January 23, 2019 10:56 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [OAUTH-WG] Shepherd write-up for
draft-ietf-oauth-resource-indicators-01
I don't think they are necessarily mutually exclusive, that is why I think
there is value in allowing them to be specified separately.
As an AS in the distributed OAuth case knowing that a client interacting with
RS https://fire.hhs.com as the resource wants a OAuth token with an audience of
HHS and a scope of read.
Without proof of possession we need to keep bad RS from asking for tokens with
scopes and audiences of other RS that can be replayed.
I really like keeping the resource simple and unspoofable, it is the URI of the
RS where you are presenting the AT.
I prefer to keep that separate from the logical resource that may span more
than one RS endpoint.
Merging the two and we are probably back at the AS looking into the URI to
figure out which one it is. I think that is harder for implementations and
more likely to have security issues down the road.
John B.
On 1/23/2019 1:44 PM, Vittorio Bertocci wrote:
Hi all,
thanks for you patience. Brian and myself iterated on modifying the text to
cover the logical identifier use case, highlighting the security implications
of going that route. You can find the revised text in
https://github.com/vibronet/i-d/blob/master/draft-ietf-oauth-resource-indicators.xml,
see the commits in the history from January 21 for the specific changes.
Note: I also had a chat with John offline, and he expressed the desire to split
the resource parameter in two distinct parameters to better signal the intended
usage. I am sure he can elaborate. I have nothing against it in principle, as
long as we leave nothing as exercise to the reader and we are very clear on
usage (e.g. mutual exclusivity, etc) but didn't have a chance to speak w Brian
about it. If the discussion stretches further, I would suggest we pause it and
let him enjoy his time off for the rest of the week.
On Mon, Jan 21, 2019 at 5:35 PM Rifaat Shekh-Yusef
<[email protected]<mailto:[email protected]>> wrote:
Thank you guys!
On Monday, January 21, 2019, Vittorio Bertocci
<[email protected]<mailto:[email protected]>> wrote:
Hi Rifaat,
absolutely. Brian and myself already started working on some language, however
this week he is in vacation hence it might take few days before we come back to
the list with something.
Cheers,
V.
On Mon, Jan 21, 2019 at 9:35 AM Rifaat Shekh-Yusef
<[email protected]<mailto:[email protected]>> wrote:
Brian, Vittorio,
To move this discussion forward, can you guys suggest some text to make the
logical identifier usage clearer?
Regards,
Rifaat
On Mon, Jan 21, 2019 at 10:32 AM Brian Campbell
<[email protected]<mailto:[email protected]>>
wrote:
As I suggested before, I do think that's within the bounds of the draft's
definition of 'resource' as a URI. And that perhaps all that's needed is some
minor adjustment and/or augmentation of some text to make it more clear.
On Sun, Jan 20, 2019 at 7:39 PM Vittorio Bertocci
<[email protected]<mailto:[email protected]>> wrote:
[sent to John only by mistake, resending to the ML]
In Azure AD v1 & ADFS, that's resource.. It could be used for both network and
logical ids, with the concrete usage in the wild I described earlier.
In Azure AD v2, the resource as explicit parameter (network, logic or
otherwise) is gone and is expressed as part of the scope string of all the
scopes requested for a given resource- but it still exist in practice tho as it
still end up in the resulting aud of the issued token.
This is 9 months old info hence
On Sun, Jan 20, 2019 at 17:58 John Bradley
<[email protected]<mailto:[email protected]>> wrote:
What is the parameter that Microsoft is using?
On 1/20/2019 3:59 PM, Vittorio Bertocci wrote:
First of all, it wasn't my intent to disrupt the established process. In my
former position I wasn't monitoring those discussions hence I didn't have a
chance to offer feedback. When I saw something that gave me the impression
might lead to issues, and given that I worked with actual deployments and
developers using a similar parameter for a long time, I thought prudent to
bring this up. I really appreciate Rifaat's stance on this. End of preamble.
Ultimately my goal is for developers to have guidance on how to work with the
concept of logical resource in a standard compliant way, hence it doesn't
strictly matter whether the definition of the corresponding parameter lives in
oauth-resource-indicators or elsewhere.
That said. Reading through the draft, it would appear that most of the reasons
for which the spec was created apply to both the network addressable and the
logical resource types: knowing what keys to use to encrypt the token,
constrain access tokens to the intended audience, avoiding overloading scopes
with resource indicating parts... those all apply to network addressable and
logic identifiers alike. And both parameters are expected to result in audience
restricted tokens. It seems the only difference comes at token usage time, with
the network addressable case giving more guarantees that the token will go to
its intended recipient, but the request and audience restriction syntax seems
to be exactly the same.
On top of this: in the 99.999% of the scenarios I encountered in the wild in
the last 5 years of using the resource parameter in the MS ecosystem, the
resource identifier was known at design time: the developer discovered it out
of band and placed it in the app config at deployment time. Those aren't fringe
cases I occasionally encountered: the resource parameter in Azure AD v1 and
ADFS was mandatory, hence literally every solution i saw or touched used it. As
Brian suggested, this is a scenario where the security advantages of the
network addressable case aren't as pronounced as in the case in which the
client discovers the resource identifier at runtime. This isn't just because
there is no specification suggesting location should be explicitly indicated,
it's because there are many practical advantages at development and deployment
time to be able to use logical identifiers- and if the concrete security
advantages don't apply to the their case, people will simply not comply.
In summary: creating two different parameters in two different documents is
better than ignoring he logical identifier case altogether, however I think
that not acknowledging the logical id case in oauth-resource-indicators is
going to create confusion and ultimately not be as useful to the developer
community as it could be.
On Sat, Jan 19, 2019 at 12:38 Phil Hunt
<[email protected]<mailto:[email protected]>> wrote:
+1 to Mike and John’s comments.
Phil
On Jan 19, 2019, at 12:34 PM, Mike Jones
<[email protected]<mailto:[email protected]>>
wrote:
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 <[email protected]<mailto:[email protected]>> On Behalf
Of John Bradley
Sent: Saturday, January 19, 2019 9:01 AM
To: Brian Campbell
<[email protected]<mailto:[email protected]>>
Cc: Vittorio Bertocci
<[email protected]<mailto:[email protected]>>;
IETF oauth WG <[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]> 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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> wrote:
Doesn’t the “scope” parameter already provide a means of specifying a logical
identifier?
--
Annabelle Richard Backman
AWS Identity
From: OAuth <[email protected]<mailto:[email protected]>> on behalf
of Vittorio Bertocci
<[email protected]<mailto:[email protected]>>
Date: Friday, January 18, 2019 at 5:47 AM
To: John Bradley <[email protected]<mailto:[email protected]>>
Cc: IETF oauth WG <[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf..org/mailman/listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
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._______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf..org/mailman/listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
