445-67 claim money Direct deposit: Acct: checking
Routing#: 031101169 Acct#: 8847548304001 Or send to my pay.google acct: [email protected] On Thu, Jan 24, 2019, 4:54 PM <[email protected]> wrote: > Send OAuth mailing list submissions to > [email protected] > > 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 protected] > > You can reach the person managing the list at > [email protected] > > 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 protected]> > To: [email protected] > Subject: Re: [OAUTH-WG] OAuth Digest, Vol 123, Issue 44 > Message-ID: > <CAKPLo8+nqDA= > [email protected]> > Content-Type: text/plain; charset="utf-8" > > Reply all > > > On Tue, Jan 22, 2019, 10:20 AM <[email protected]> wrote: > > > Send OAuth mailing list submissions to > > [email protected] > > > > 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 protected] > > > > You can reach the person managing the list at > > [email protected] > > > > 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 protected]> > > To: Rifaat Shekh-Yusef <[email protected]>, Vittorio Bertocci > > <[email protected]> > > Cc: Brian Campbell <[email protected]>, IETF > > oauth WG <[email protected]> > > Subject: Re: [OAUTH-WG] Shepherd write-up for > > draft-ietf-oauth-resource-indicators-01 > > Message-ID: > > < > > > mw2pr00mb030099e717a31d46bcaa4f9af5...@mw2pr00mb0300.namprd00.prod.outlook.com > > > > > > > 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 protected]> On Behalf Of Rifaat Shekh-Yusef > > Sent: Monday, January 21, 2019 5:36 PM > > To: Vittorio Bertocci <[email protected]> > > Cc: Brian Campbell <[email protected]>; IETF > > oauth WG <[email protected]> > > 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 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 <bcampbell= > > [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 <Michael.Jones= > > [email protected]<mailto:Michael.Jones= > > [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: > Vittorio > > [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 > > -------------- 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 protected] > > 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 protected] > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 123, Issue 56 > ************************************** >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
