Re: [OAUTH-WG] Registration: Scope Values

[Justin Richer <[e-mail]>]

I wholeheartedly agree that scope at registration is a useful part of 
the lifecycle (and indeed, a required part of our own implementation of 
this very functionality). But the way I read it, the requirement of "all 
scopes ... MAY use" is too restrictive and it's open to 
misinterpretation, I think. If a client registers for "A" but asks for 
"A:b?param=foo", is that OK? This is the pattern that we've been talking 
about using with Blue Button [1], but it seems precluded by this 
definition if you've got a tight definition of "MAY use". In the case of 
simple strings, it's adequate, and I think that's the common case, but 
we don't want to restrict the usefulness of this field to the simple 
case. I had tried to address this with enumerating string matching and 
other things, others have suggested defining a regular expression 
language, but at the end of the day I don't think any of that actually 
buys you much interoperability.

  -- Justin

[1] http://blue-button.github.io/blue-button-plus-pull/

On 04/18/2013 01:54 PM, Phil Hunt wrote:
> Why not:
>
>> "A value corresponding to scope as described in OAuth 2, Section 3.3 
>> [RFC6749]. The registered Client may use these to indicate all of the 
>> scopes that a client MAY use when requesting tokens from an 
>> Authorization Server."
>
> In the above, I avoid re-defining scope at all. However describing why 
> they are included in registration is useful.  IMHO I think scope at 
> registration is useful for life-cycle approval workflows.
>
> In some cases you could say they are also the default list, but I'm 
> not sure it helps inter-operability so its not clear it needs to be 
> mentioned.
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [e-mail] <mailto:[e-mail]>
>
>
>
>
>
> On 2013-04-18, at 10:47 AM, Justin Richer wrote:
>
>> Thing is, there's nothing normative about the enforcing statement 
>> that I made below, so I don't think it's any more restrictive than 
>> RFC 6749 which lets the AS replace a client's requested scopes at the 
>> time of token issuance with whatever it pleases. But that said, I'd 
>> be just as happy to leave it like this with no further restrictions:
>>
>> Space-separated list of scope values (as described in OAuth 2.0 
>> Section 3.3 [RFC6749] 
>> <http://tools.ietf.org/html/rfc6749#section-3.3>) that the Client can 
>> use when requesting access tokens from the Authorization Server.
>>
>> And call it a day. This parallels the text for grant_types ("Array of 
>> OAuth 2.0 grant types that the Client may use [when accessing the 
>> Token Endpoint].") and response_types ("Array of the OAuth 2.0 
>> response types that the Client may use [when accessing the 
>> Authorization Endpoint]."), and I think this is the correct approach. 
>> I only started to add the restrictive text because I thought that 
>> people were making the argument that it was necessary -- I'd rather 
>> not have it.
>> Plus, it's an optional field in the metadata, so if you've got 
>> structured scopes where this doesn't make sense, don't use it. If you 
>> don't do a per-client scope restriction, don't use it.
>>
>> The interoperability is defined in light of the interoperability of 
>> scopes themselves: this is a field to request/grant a bag of strings 
>> that only make sense in light of a given API. For that to make real 
>> sense, I think that we need to differentiate an OAuth client as a 
>> generic *library* from an OAuth client as a generic accessing 
>> *application*. It's very useful for a generic *library* that handles 
>> the authorization layer for an application to have a slot for 
>> registering scopes and finding out what scopes the app's been 
>> registered for. It's up to the app (not the library) to figure out 
>> how to translate those into scopes to ask for at authorization time. 
>> Sometimes that means just passing the string, and sometimes it means 
>> the construction of a structured value like 
>> "urn:example:channel=HBO&urn:example:rating=G,PG-13". The library 
>> doesn't care, the application does, and we should focus on 
>> interoperability from the library's perspective. Similarly, on the 
>> server side, the libraries will tell you the bag of scopes that the 
>> client was registered for, and what bag of scopes the client asked 
>> for during authorization. It's up to the server *application* to 
>> harmonize those two in a way that makes sense for the API that it's 
>> protecting. Just like it's up to the protected resource *application* 
>> to figure out what a scope means in a given context.
>>
>> So let's just leave it unrestricted but keep the slot for 
>> communicating this piece of information with the same semantics that 
>> the communication between the client and server take on for every 
>> other field: client asks for a thing, server says that client 
>> actually gets a thing, and it's implicitly up to the server to do the 
>> right thing and enforce things in a way that makes sense for the 
>> application no matter what the client does.
>>
>> To take Tony's example, client requests no scopes at registration, 
>> server grants scope "A" at registration. Client then requests scope 
>> "X" at authorization, server is free to deny the request 
>> (invalid_scope error), allow authorization because it knows how "A" 
>> and "X" are related, require user intervention, or really, whatever 
>> it likes. The libraries, where I argue the interoperability cries 
>> really matter, don't care, and shouldn't care.
>>
>>  -- Justin
>>
>> On 04/18/2013 01:04 PM, Mike Jones wrote:
>>>
>>> Saying anything normative about “enforcing restrictions” is going 
>>> beyond RFC 6749 semantics.  Indeed, you’d said that “I agree that we 
>>> shouldn't try to "solve" scope in registration.”, but talking about 
>>> restrictions is going down the slippery “solving it” path.
>>>
>>> At most we can say that the two parties are making declarations to 
>>> one another about scopes that they may choose to use, but we can’t 
>>> assume that this is an exclusive list and that other scope values 
>>> such as “urn:example:channel=HBO&urn:example:rating=G,PG-13” might 
>>> not be used, even if the client registers saying that it intends to 
>>> use the “OATC” scope value.  We could maybe even say that some 
>>> services may use a static set of scopes and might choose to limit 
>>> the scopes that a client may use to those that it declared to the 
>>> server or to those that the server returned to the client.  That’s a 
>>> HINT that some services might do this.  But we can’t say anything 
>>> normative about such possible behaviors, because it goes beyond RFC 
>>> 6749.
>>>
>>> -- Mike
>>>
>>> *From:*Richer, Justin P. [mailto:[e-mail]]
>>> *Sent:* Thursday, April 18, 2013 9:26 AM
>>> *To:* Anthony Nadalin
>>> *Cc:* Tim Bray; Mike Jones; [e-mail]
>>> *Subject:* Re: [OAUTH-WG] Registration: Scope Values
>>>
>>> This doesn't actually break the semantics because the client MUST 
>>> accept what the server tells it over anything that it asks for in 
>>> the first place. The server has the final say. So in this case, if 
>>> your client asks for nothing, the server says "A B C", the client 
>>> now knows it can ask for "A B C" scopes.
>>>
>>> I'm still in favor of not putting the restricting language in the 
>>> scope definition at all, instead have it say something like:
>>>
>>>     “Space-separated list of scope values (as described in OAuth 2.0
>>>     Section 3.3 [RFC6749]
>>>     <http://tools.ietf.org/html/rfc6749#section-3.3>) that the
>>>     Client can use when requesting access tokens from the
>>>     Authorization Server. As scope values are service specific, the
>>>     means of the Authorization Server enforcing this restriction are
>>>     outside the scope of this specification.”
>>>
>>> Couple this with the overall paragraph that says that the client is 
>>> requesting values that the server is potentially overriding with its 
>>> declarations, and I think that addresses everything without getting 
>>> into confusing language that doesn't add to interoperability.
>>>
>>>  -- Justin
>>>
>>> On Apr 18, 2013, at 12:13 PM, Anthony Nadalin <[e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>>
>>>
>>>
>>> If I don’t specify a scope, then the server can allocate a default 
>>> (or default set), thus that breaks the semantics you describe
>>>
>>> *From:*[e-mail] <mailto:[e-mail]> 
>>> [mailto:[e-mail] <mailto:[e-mail]>]*On Behalf 
>>> Of*Tim Bray
>>> *Sent:*Thursday, April 18, 2013 9:04 AM
>>> *To:*Mike Jones
>>> *Cc:*[e-mail] <mailto:[e-mail]>
>>> *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>>
>>> I’m unconvinced, Mike.  Obviously you’re right about the looseness 
>>> of OAuth2 scope specification, but this is a very specific semantic 
>>> of what happens when you register, and I don’t think we’re bound by 
>>> history here. If we can’t safely say anything about what the list of 
>>> scopes means, then I'm with you let's take them out.  But the most 
>>> obvious intended semantic is (from the client) “I promise to ask 
>>> only for these” and from the server “These are the only ones I’ll 
>>> give you tokens for.”  Or does someone have use-cases for an 
>>> alternative semantic?
>>>
>>> To make this concrete, I propose the following:
>>>
>>> “Space-separated list of scope values (as described in OAuth 2.0 
>>> Section 3.3 [RFC6749] 
>>> <http://tools.ietf.org/html/rfc6749#section-3.3>) that the client is 
>>> declaring to the server that it will restrict itself to when 
>>> requesting access tokens, and that the server is declaring to the 
>>> client that it is registered to use when requesting access tokens. 
>>> Clients SHOULD assume that servers will refuse to grant access 
>>> tokens for scopes not in the list provided by the server.”
>>>
>>> On Thu, Apr 18, 2013 at 8:55 AM, Mike Jones 
>>> <[e-mail] <mailto:[e-mail]>> 
>>> wrote:
>>>
>>>     I don’t think it’s possible to define what it means in an
>>>     interoperable way because OAuth didn’t specify scopes in an
>>>     interoperable way.  No, I don’t like that either, but I think
>>>     that’s where things are. That’s why I was advocating deleting
>>>     this registration feature entirely.
>>>
>>>     But understanding it might be useful in some contexts, I’m OK
>>>     keeping it, provided we be clear that the semantics of
>>>     “registered to use” are service-specific.
>>>
>>>     -- Mike
>>>
>>>     *From:*Tim Bray [mailto:[e-mail]
>>>     <mailto:[e-mail]>]
>>>     *Sent:*Thursday, April 18, 2013 8:36 AM
>>>     *To:*Mike Jones
>>>     *Cc:*Justin Richer;[e-mail] <mailto:[e-mail]>
>>>
>>>
>>>     *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>>
>>>     On the server-to-client side, what does “registered to use”
>>>     mean?  Does it mean that the client should assume that any
>>>     scopes not on the list WILL not be granted, MAY not be
>>>     granted.... or what?  Is this already covered elsewhere? -T
>>>
>>>     On Thu, Apr 18, 2013 at 8:28 AM, Mike Jones
>>>     <[e-mail]
>>>     <mailto:[e-mail]>> wrote:
>>>
>>>     Thanks, Justin.  I agree with the need for the generic two-sided
>>>     language.  I’d still keep this language for scope, because we
>>>     want to capture the “declaring” aspect in this case:
>>>
>>>     “Space separated list of scope values (as described in OAuth
>>>     2.0Section 3.3 [RFC6749]
>>>     <http://tools.ietf.org/html/rfc6749#section-3.3>) that the
>>>     client is declaring to the server that it may use when
>>>     requesting access tokens and that the server is declaring to the
>>>     client that it is registered to use when requesting access tokens.”.
>>>
>>>     You should probably also reinforce that scope values are
>>>     service-specific and may not consist only of a static set of
>>>     string values, and that therefore, in some cases, an exhaustive
>>>     list of registered scope values is not possible.
>>>
>>>     -- Mike
>>>
>>>     *From:*Justin Richer [mailto:[e-mail]
>>>     <mailto:[e-mail]>]
>>>     *Sent:*Monday, April 15, 2013 12:29 PM
>>>
>>>
>>>     *To:*Mike Jones
>>>     *Cc:*Tim Bray;[e-mail] <mailto:[e-mail]>
>>>     *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>>
>>>     I think that because the "declaration" issue affects all
>>>     parameters in the list, not just scope, we should adopt this in
>>>     a higher level paragraph and leave it out of the individual
>>>     parameter descriptions. Thus, something like this inserted as
>>>     the second paragraph in section 2:
>>>
>>>     The client metadata values serve two parallel purposes in the
>>>     overall OAuth Dynamic Registration protocol:
>>>
>>>      - the Client requesting its desired values for each parameter
>>>     to the Authorization Server in a [register] or [update] request,
>>>      - the Authorization Server informing the Client of the current
>>>     values of each parameter that the Client has been registered to
>>>     use through a [client information response].
>>>
>>>     An Authorization Server MAY override any value that a Client
>>>     requests during the registration process (including any omitted
>>>     values) and replace the requested value with a default. The
>>>     normative indications in the following list apply to the
>>>     Client's declaration of its desired values.
>>>
>>>     The Authorization Server SHOULD provide documentation for any
>>>     fields that it requires to be filled in by the client or to have
>>>     particular values or formats. Extensions and profiles...
>>>
>>>
>>>     And then remove the sidedness-language from the scope parameter
>>>     and any other parameters where it might have crept in inadvertently.
>>>
>>>      -- Justin
>>>
>>>     On 04/15/2013 01:29 PM, Mike Jones wrote:
>>>
>>>         We could fix the one-sided language by changing
>>>
>>>         “Space separated list of scope values (as described in OAuth
>>>         2.0Section 3.3 [RFC6749]
>>>         <http://tools.ietf.org/html/rfc6749#section-3.3>) that the
>>>         client is declaring that it may use when requesting access
>>>         tokens.”
>>>
>>>         to
>>>
>>>         “Space separated list of scope values (as described in OAuth
>>>         2.0Section 3.3 [RFC6749]
>>>         <http://tools.ietf.org/html/rfc6749#section-3.3>) that the
>>>         client is declaring to the server that it may use when
>>>         requesting access tokens and that the server is declaring to
>>>         the client that it is registered to use when requesting
>>>         access tokens.”.
>>>
>>>         Again, I chose the “registered to use” language carefully –
>>>         because in the general case it’s not a restriction on the
>>>         values that the client can use – just a statement by the
>>>         server to the client that it is registered to use those
>>>         particular values.  In both cases, the parties are making
>>>         declarations to one another.
>>>
>>>         If you adopt that language (or keep the original language),
>>>         then yes, I’d consider this closed.
>>>
>>>         -- Mike
>>>
>>>         *From:*Justin Richer [mailto:[e-mail]]
>>>         *Sent:*Monday, April 15, 2013 9:57 AM
>>>         *To:*Mike Jones
>>>         *Cc:*Tim Bray;[e-mail] <mailto:[e-mail]>
>>>         *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>>
>>>         I absolutely do not want to delete this feature, as (having
>>>         implemented it) I think it's very useful. This is a very
>>>         established pattern in manual registration: I know of many,
>>>         many OAuth2 servers and clients that are set up where the
>>>         client must pre-register a set of scopes.
>>>
>>>         I don't like the language of "the client is declaring"
>>>         because it's too one-sided. The client might not have
>>>         declared anything, and it might be the server that's
>>>         declaring something to the client. Deleting the "is
>>>         declaring" bit removes that unintended restriction of the
>>>         language while keeping the original meaning intact. I
>>>         actually thought that I had fixed that before the last draft
>>>         went in but apparently I missed this one.
>>>
>>>         I will work on clarifying the intent of the whole metadata
>>>         set in its introductory paragraph(s) so that it's clear that
>>>         all of these fields are used in both of these situations:
>>>
>>>          1) The client declaring to the server its desire to use a
>>>         particular value
>>>          2) The server declaring to the client that it has been
>>>         registered with a particular value
>>>
>>>         This should hopefully clear up the issue in the editor's
>>>         note that I currently have at the top of that section right
>>>         now, too.
>>>
>>>         Mike, since you were the one who originally brought up the
>>>         issue, and you're fine with the existing text, can I take
>>>         this as closed now? Assuming that you agree with deleting
>>>         "is declaring" for reasons stated above, I'm fine with
>>>         leaving everything else as is and staying quiet on what the
>>>         server has to do with the scopes.
>>>
>>>          -- Justin
>>>
>>>         On 04/15/2013 12:44 PM, Mike Jones wrote:
>>>
>>>             I think that the existing wording is superior to the
>>>             proposed changed wording.  The existing wording is:
>>>
>>>                scope
>>>
>>>             OPTIONAL.  Space separated list of scope values (as
>>>             described in
>>>
>>>                   OAuth 2.0Section 3.3 [RFC6749]
>>>             <http://tools.ietf.org/html/rfc6749#section-3.3>) that
>>>             the client is declaring that
>>>
>>>                   it may use when requesting access tokens.  If
>>>             omitted, an
>>>
>>>             Authorization Server MAY register a Client with a
>>>             default set of
>>>
>>>             scopes.
>>>
>>>             For instance, the current “client is declaring” wording
>>>             will always be correct, whereas as the change to “client
>>>             can use” wording implies a restriction on client
>>>             behavior that is not always applicable.  The “client is
>>>             declaring” wording was specific and purposefully chosen,
>>>             and I think should be retained. In particular, we can’t
>>>             do anything that implies that only the registered scopes
>>>             values can be used. At the OAuth spec level, this is a
>>>             hint as to possible future client behavior – not a
>>>             restriction on future client behavior.
>>>
>>>             Also, for the reasons that Tim stated, I’m strongly
>>>             against any “matching” or “regex” language in the spec
>>>             pertaining to scopes – as it’s not actionable.
>>>
>>>             So I’d propose that we leave the existing scope wording
>>>             in place.  Alternatively, I’d also be fine with deleting
>>>             this feature entirely, as I don’t think it’s useful in
>>>             the general case.
>>>
>>>             -- Mike
>>>
>>>             *From:*[e-mail]
>>>             <mailto:[e-mail]>[mailto:[e-mail]]*On
>>>             Behalf Of*Justin Richer
>>>             *Sent:*Monday, April 15, 2013 8:05 AM
>>>             *To:*Tim Bray;[e-mail] <mailto:[e-mail]>
>>>             *Subject:*Re: [OAUTH-WG] Registration: Scope Values
>>>
>>>             On 04/15/2013 10:52 AM, Tim Bray wrote:
>>>
>>>
>>>             I’d use the existing wording; it’s perfectly clear.
>>>              Failing that, if there’s strong demand for registration
>>>             of structured scopes, bless the use of regexes, either
>>>             PCREs or some careful subset.
>>>
>>>
>>>             Thanks for the feedback -- Of these two choices, I'd
>>>             rather leave it as-is.
>>>
>>>
>>>
>>>             However, I’d subtract the sentence “If omitted, an
>>>             Authorization Server MAY register a Client with a
>>>             default set of  scopes.”  It adds no value; if the
>>>             client doesn’t declare scopes, the client doesn’t
>>>             declare scopes, that’s all.  -T
>>>
>>>
>>>             Remember, all of these fields aren't just for the client
>>>             *request*, they're also for the server's *response* to
>>>             either a POST, PUT, or GET request. (I didn't realize
>>>             it, but perhaps the wording as stated right now doesn't
>>>             make that clear -- I need to fix that.) The value that
>>>             it adds is if the client doesn't ask for any particular
>>>             scopes, the server can still assign it scopes and the
>>>             client can do something smart with that. Dumb clients
>>>             are allowed to ignore it if it doesn't mean anything to
>>>             them.
>>>
>>>             This is how our server implementation actually works
>>>             right now. If the client doesn't ask for anything
>>>             specific at registration, the server hands it a bag of
>>>             "default" scopes. Same thing happens at auth time -- if
>>>             the client doesn't ask for any particular scopes, the
>>>             server hands it all of its registered scopes as a
>>>             default. Granted, on our server, scopes are just simple
>>>             strings right now, so they get compared at the auth
>>>             endpoint with an exact string-match metric and set-based
>>>             logic.
>>>
>>>              -- Justin
>>>
>>>
>>>
>>>             On Mon, Apr 15, 2013 at 7:35 AM, Justin Richer
>>>             <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>             What would you suggest for wording here, then? Keeping
>>>             in mind that we cannot (and don't want to) prohibit
>>>             expression-based scopes.
>>>
>>>              -- Justin
>>>
>>>             On 04/15/2013 10:33 AM, Tim Bray wrote:
>>>
>>>                 No, I mean it’s not interoperable at the
>>>                 software-developer level.  I can’t register scopes
>>>                 at authorization time with any predictable effect
>>>                 that I can write code to support, either client or
>>>                 server side, without out-of-line non-interoperable
>>>                 knowledge about the behavior of the server.
>>>
>>>                 I guess I’m just not used to OAuth’s culture of
>>>                 having no expectation that things will be specified
>>>                 tightly enough that I can write code to implement as
>>>                 specified.  -T
>>>
>>>                 On Mon, Apr 15, 2013 at 7:15 AM, Justin Richer
>>>                 <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>                 Scopes aren't meant to be interoperable between
>>>                 services since they're necessarily API-specific. The
>>>                 only interoperable bit is that there's *some* place
>>>                 to put the values and that it's expressed as a bag
>>>                 of space-separated strings. How those strings get
>>>                 interpreted and enforced (which is really what's at
>>>                 stake here) is up to the AS and PR (or a
>>>                 higher-level protocol like UMA).
>>>
>>>                  -- Justin
>>>
>>>                 On 04/15/2013 10:13 AM, Tim Bray wrote:
>>>
>>>                     This, as written, has zero interoperability. I
>>>                     think this feature can really only be made
>>>                     useful in the case where scopes are fixed strings.
>>>
>>>                     -T
>>>
>>>                     On Apr 15, 2013 6:54 AM, "Justin Richer"
>>>                     <[e-mail] <mailto:[e-mail]>>
>>>                     wrote:
>>>
>>>                     You are correct that the idea behind the "scope"
>>>                     parameter at registration is a constraint on
>>>                     authorization-time scopes that are made
>>>                     available. It's both a means for the client to
>>>                     request a set of valid scopes and for the server
>>>                     to provision (and echo back to the client) a set
>>>                     of valid scopes.
>>>
>>>                     I *really* don't want to try to define a
>>>                     matching language for scope expressions. For
>>>                     that to work, all servers would need to be able
>>>                     to process the regular expressions for all
>>>                     clients, even if the servers themselves only
>>>                     support simple-string scope values. Any regular
>>>                     expression syntax we pick here is guaranteed to
>>>                     be incompatible with something, and I think the
>>>                     complexity doesn't buy much. Also, I think you
>>>                     suddenly have a potential security issue if you
>>>                     have a bad regex in place on either end.
>>>
>>>                     As it stands today, the server can interpret the
>>>                     incoming registration scopes and enforce them
>>>                     however it wants to. The real trick comes not
>>>                     from assigning the values to a particular client
>>>                     but to enforcing them, and I think that's always
>>>                     going to be service-specific. We're just not as
>>>                     clear on that as we could be.
>>>
>>>                     After looking over everyone's comments so far,
>>>                     I'd like to propose the following text for that
>>>                     section:
>>>
>>>
>>>                         scope
>>>
>>>                            OPTIONAL.  Space separated list of scope values (as described in
>>>
>>>                            OAuth 2.0Section 3.3 [RFC6749]  <http://tools.ietf.org/html/rfc6749#section-3.3>) that the client can use when
>>>
>>>                            requesting access tokens.  As scope values are service-specific,
>>>
>>>                            the Authorization Server MAY define its own matching rules when
>>>
>>>                            determining if a scope value used during an authorization request
>>>
>>>                            is valid according to the scope values assigned during
>>>
>>>                            registration. Possible matching rules include wildcard patterns,
>>>
>>>                            regular expressions, or exactly matching the string. If omitted,
>>>
>>>                            an Authorization Server MAY register a Client with a default
>>>
>>>                            set of scopes.
>>>
>>>
>>>                     Comments? Improvements?
>>>
>>>                      -- Justin
>>>
>>>
>>>                     On 04/14/2013 08:23 PM, Manger, James H wrote:
>>>
>>>                         Presumably at app registration time any scope specification is really a constraint on the scope values that can be requested in an authorization flow.
>>>
>>>                           
>>>
>>>                         So ideally registration should accept rules for matching scopes, as opposed to actual scope values.
>>>
>>>                           
>>>
>>>                         You can try to use scope values as their own matching rules. That is fine for a small set of "static" scopes. It starts to fail when there are a large number of scopes, or scopes that can include parameters (resource paths? email addresses?). You can try to patch those failures by allowing services to define service-specific special "wildcard" scope values that can only be used during registration (eg "read:*").
>>>
>>>                           
>>>
>>>                         Alternatively, replace 'scope' in registration with 'scope_regex' that holds a regular expression that all scope values in an authorization flow must match.
>>>
>>>                           
>>>
>>>                         --
>>>
>>>                         James Manger
>>>
>>>                         _______________________________________________
>>>
>>>                         OAuth mailing list
>>>
>>>                         [e-mail]  <mailto:[e-mail]>
>>>
>>>                         https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>                     _______________________________________________
>>>                     OAuth mailing list
>>>                     [e-mail] <mailto:[e-mail]>
>>>                     https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>