Subject: Re: [OAUTH-WG] OAuth Digest, Vol 123, Issue 56

From: Lao Vang <[email-masked]>
Date: Thu, 24 Jan 2019 17:17:25 -0800

445-67 claim money

Direct deposit:
Acct: checking

Routing#: 031101169
Acct#: 8847548304001

Or send to my pay.google acct:

[email-masked]

On Thu, Jan 24, 2019, 4:54 PM <[email-masked]> wrote:

> Send OAuth mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
>
> Today's Topics:
>
>    1. Re: OAuth Digest, Vol 123, Issue 44 (Lao Vang)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 24 Jan 2019 16:51:52 -0800
> From: Lao Vang <[email-masked]>
> To: [email-masked]
> Subject: Re: [OAUTH-WG] OAuth Digest, Vol 123, Issue 44
> Message-ID:
>         <CAKPLo8+nqDA=
> [email-masked]>
> Content-Type: text/plain; charset="utf-8"
>
> Reply all
>
>
> On Tue, Jan 22, 2019, 10:20 AM <[email-masked]> wrote:
>
> > Send OAuth mailing list submissions to
> >         [email-masked]
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >         https://www.ietf.org/mailman/listinfo/oauth
> > or, via email, send a message with subject or body 'help' to
> >         [email-masked]
> >
> > You can reach the person managing the list at
> >         [email-masked]
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of OAuth digest..."
> >
> >
> > Today's Topics:
> >
> >    1. Re: Shepherd write-up for
> >       draft-ietf-oauth-resource-indicators-01 (Mike Jones)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 22 Jan 2019 18:19:31 +0000
> > From: Mike Jones <[email-masked]>
> > To: Rifaat Shekh-Yusef <[email-masked]>, Vittorio Bertocci
> >         <[email-masked]>
> > Cc: Brian Campbell <bcampbell=[email-masked]>, IETF
> >         oauth WG <[email-masked]>
> > Subject: Re: [OAUTH-WG] Shepherd write-up for
> >         draft-ietf-oauth-resource-indicators-01
> > Message-ID:
> >         <
> >
> [email-masked]
> > >
> >
> > Content-Type: text/plain; charset="utf-8"
> >
> > I think that a non-normative reference to  ?req_aud? in
> > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-01 should be
> > added to the resource indicators doc to inform developers that req_aud is
> > also available to then, and then we should call it a day.
> >
> >                                                                 -- Mike
> >
> > From: OAuth <[email-masked]> On Behalf Of Rifaat Shekh-Yusef
> > Sent: Monday, January 21, 2019 5:36 PM
> > To: Vittorio Bertocci <[email-masked]>
> > Cc: Brian Campbell <bcampbell=[email-masked]>; IETF
> > oauth WG <[email-masked]>
> > Subject: Re: [OAUTH-WG] Shepherd write-up for
> > draft-ietf-oauth-resource-indicators-01
> >
> > Thank you guys!
> >
> >
> > On Monday, January 21, 2019, Vittorio Bertocci <[email-masked]
> <mailto:
> > [email-masked]>> 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-masked]
> > <mailto:[email-masked]>> 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 <bcampbell=
> > [email-masked]<mailto:
> [email-masked]>>
> > 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-masked]
> > <mailto:[email-masked]>> 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-masked]<mailto:
> > [email-masked]>> 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-masked]<mailto:
> > [email-masked]>> wrote:
> > +1 to Mike and John?s comments.
> > Phil
> >
> > On Jan 19, 2019, at 12:34 PM, Mike Jones <Michael.Jones=
> > [email-masked]<mailto:Michael.Jones=
> > [email-masked]>> 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-masked]<mailto:[email-masked]>> On
> > Behalf Of John Bradley
> > Sent: Saturday, January 19, 2019 9:01 AM
> > To: Brian Campbell <[email-masked]<mailto:
> > [email-masked]>>
> > Cc: Vittorio Bertocci <Vittorio=[email-masked]<mailto:
> Vittorio
> > =[email-masked]>>; IETF oauth WG <[email-masked]<mailto:
> > [email-masked]>>
> > 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-masked]
> > <mailto:[email-masked]> 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-masked]
> > <mailto:[email-masked]>> 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-masked]
> > <mailto:[email-masked]>> 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-masked]
> > <mailto:[email-masked]>> 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-masked]<mailto:
> > [email-masked]>> 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-masked]<mailto:[email-masked]>> wrote:
> > Doesn?t the ?scope? parameter already provide a means of specifying a
> > logical identifier?
> >
> > --
> > Annabelle Richard Backman
> > AWS Identity
> >
> >
> > From: OAuth <[email-masked]<mailto:[email-masked]>> on
> > behalf of Vittorio Bertocci <Vittorio=[email-masked]<mailto:
> > [email-masked]>>
> > Date: Friday, January 18, 2019 at 5:47 AM
> > To: John Bradley <[email-masked]<mailto:[email-masked]>>
> > Cc: IETF oauth WG <[email-masked]<mailto:[email-masked]>>
> > 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-masked]<mailto:
> > [email-masked]>> 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-masked]
> > <mailto:[email-masked]>> 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-masked]
> > <mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > _______________________________________________
> >
> > OAuth mailing list
> >
> > [email-masked]<mailto:[email-masked]>
> >
> > https://www.ietf..org/mailman/listinfo/oauth<
> > https://www.ietf.org/mailman/listinfo/oauth>
> > _______________________________________________
> > OAuth mailing list
> > [email-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/oauth
> > _______________________________________________
> > OAuth mailing list
> > [email-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/oauth
> > _______________________________________________
> > OAuth mailing list
> > [email-masked]<mailto:[email-masked]>
> > 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-masked]<mailto:[email-masked]>
> > 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-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/oauth
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> >
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190122/f5c4761d/attachment.html
> > >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > OAuth mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > ------------------------------
> >
> > End of OAuth Digest, Vol 123, Issue 44
> > **************************************
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190124/50055095/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 123, Issue 56
> **************************************
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 24 Jan 2019 21:20:39 -0500

Please, do not send him money :)

I unsubscribed and blocked this email from the list.

Regards,
 Rifaat

On Thu, Jan 24, 2019 at 8:18 PM Lao Vang <[email-masked]> wrote:

>> <MW2PR00MB030099E717A31D46BCAA4F9AF5980@MW2PR00MB0300..namprd00.prod.outlook.com>
>> > >
>> >
>> > Vittorio@auth0..com <[email-masked]>>> wrote:
>> > Hi Rifaat,
>> > Azure AD v1 and ADFS was mandatory, hence literally every solution i
>> saw or
>> > to these kinds of threads is hard for me and I'll just get over it....
>> >
>> > actual location in that context ,along with some other checks
>> prescribed in
>> > how it talks about the value of the 'resource' parameter. But
>> ultimately it
>> > parameter value that's a logical identifier that points to some
>> resource is