Reply all
On Wed, Jan 23, 2019, 8:45 AM <oauth-requ...@ietf.org> wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > 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 > oauth-requ...@ietf.org > > You can reach the person managing the list at > oauth-ow...@ietf.org > > 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 (Vittorio Bertocci) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 23 Jan 2019 08:44:43 -0800 > From: Vittorio Bertocci <vitto...@auth0.com> > To: Rifaat Shekh-Yusef <rifaat.i...@gmail.com> > Cc: Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org>, > IETF oauth WG <oauth@ietf.org> > Subject: Re: [OAUTH-WG] Shepherd write-up for > draft-ietf-oauth-resource-indicators-01 > Message-ID: > < > cao_fve6+2eexcqkreknv43stoasa8-+rmrzek7_ehjk+oa7...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 <rifaat.i...@gmail.com> > wrote: > > > Thank you guys! > > > > > > On Monday, January 21, 2019, Vittorio Bertocci <vitto...@auth0.com> > 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 < > rifaat.i...@gmail.com> > >> 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= > >>> 40pingidentity....@dmarc.ietf.org> 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 <vitto...@auth0.com > > > >>>> 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 <ve7...@ve7jtb.com> > 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 <phil.h...@oracle.com> > wrote: > >>>>>> > >>>>>>> +1 to Mike and John?s comments. > >>>>>>> > >>>>>>> Phil > >>>>>>> > >>>>>>> On Jan 19, 2019, at 12:34 PM, Mike Jones < > >>>>>>> Michael.Jones=40microsoft....@dmarc.ietf.org> 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 <oauth-boun...@ietf.org> *On Behalf Of * John > Bradley > >>>>>>> *Sent:* Saturday, January 19, 2019 9:01 AM > >>>>>>> *To:* Brian Campbell <bcampb...@pingidentity.com> > >>>>>>> *Cc:* Vittorio Bertocci <Vittorio=40auth0....@dmarc.ietf.org>; > IETF > >>>>>>> oauth WG <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 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> 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> 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> 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> > >>>>>>> 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> 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> on behalf of Vittorio > >>>>>>> Bertocci <Vittorio=40auth0....@dmarc.ietf.org > >>>>>>> <40auth0.....@dmarc.ietf.org>> > >>>>>>> *Date: *Friday, January 18, 2019 at 5:47 AM > >>>>>>> *To: *John Bradley <ve7...@ve7jtb.com> > >>>>>>> *Cc: *IETF oauth WG <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> > >>>>>>> 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> 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> 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 > >>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> > >>>>>>> OAuth mailing list > >>>>>>> > >>>>>>> OAuth@ietf.org > >>>>>>> > >>>>>>> https://www.ietf..org/mailman/listinfo/oauth < > https://www.ietf.org/mailman/listinfo/oauth> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> OAuth mailing list > >>>>>>> OAuth@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> OAuth mailing list > >>>>>>> OAuth@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> OAuth mailing list > >>>>>>> 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 > >>>>>>> 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 > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20190123/9199c27a/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 123, Issue 45 > ************************************** >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
