I know that at least in Azure, developers can dynamically add resources for use
by the client using the developer portal at any time. Therefore, at client
configuration time, which is when AS discovery is used, there is not an
authoritative list of resources available. I believe that Brian said a similar
thing about his use cases.
Therefore, while what you’re proposing may *seem*, simple, but it’s *not
actually* simple at all.
-- Mike
From: Phil Hunt [mailto:[email protected]]
Sent: Saturday, February 27, 2016 10:57 AM
To: Mike Jones <[email protected]>
Cc: Vladimir Dzhuvinov <[email protected]>; [email protected]
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
To clarify…. I am not suggesting that we need a resource discovery mechanism.
What I am suggesting is much simpler.
I propose that the authorization confirm that the endpoint that the client has
discovered is a resource that the AS can issue tokens for (in other words is a
valid audience for the tokens).
This will work well in UMA cases and it confirms the relationship between the
AS and the RS is in fact valid.
It also detects mis-configuration cases that might naturally occur in scenarios
with multi-tenancies etc.
Phil
@independentid
www.independentid.com<http://www.independentid.com>
[email protected]<mailto:[email protected]>
On Feb 27, 2016, at 10:38 AM, Mike Jones
<[email protected]<mailto:[email protected]>> wrote:
Thanks for taking the time to propose specific text, Phil. That’s really
helpful. I’ll plan to incorporate a version of this in the draft addressing
WGLC comments.
I agree with Vladimir’s observation that it’s difficult to come up with a
general-purpose resource discovery mechanism. That in part, is because, as
Brian points out, there’s often not a 1:1 relationship between authorization
servers and resource servers. As I’ve written before, I do encourage the
working group to work on creating solutions to resource discovery that will
work for some common use cases. But the good news is that while resource
discovery requires new invention, authorization server discovery does not.
-- Mike
From: OAuth [mailto:[email protected]] On Behalf Of Vladimir Dzhuvinov
Sent: Saturday, February 27, 2016 10:33 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
On 27/02/16 20:10, Phil Hunt wrote:
The name change seems appropriate given that the WG members have decided not to
address the issue of resource discovery as part of this specification.
If the consensus is to limit the scope of the specification, then I suggest the
following security considerations text.
Resource Discovery
Secure discovery of resource endpoints is out-of-scope of this specification.
This specification assumes that the client has already securely discovered the
correct resource endpoint and that the client has correctly selected the
correct corresponding discovery for OAuth Authorization server. Implementers
MUST consider that if an incorrect resource endpoint was discovered by the
client that an attacker will be able to set up a man-in-the-middle proxy to a
real resource server without detection by the authorization server or the
client.
I support that. This was the primary concern of everyone who felt uncomfortable
with the original draft with WebFinger-based discovery in it, so it should be
included.
It may be more appropriate to even include this text in the introduction as a
cautionary "red flag" to implementers.
+1
Once again, I strongly urge the WG to actually include a method for the client
to discovery that the oauth cliet has correctly discovered an authorization
server that is willing and able to issue access tokens for a given resource
endpoint. I believe this relationship is critical to security of OAuth in cases
where resource endpoints are discovered dynamically. Of course willing and
able means that the AS believes that the endpoint is legitimate.
The more I think about this topic, the more pessimistic I get that there is a
good solution to this :)
Vladimir
Phil
@independentid
www.independentid.com<http://www.independentid.com/>
<http://www.independentid.com/><http://www.independentid.com/>[email protected]<mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
On Feb 27, 2016, at 6:46 AM, Samuel Erdtman
<[email protected]><mailto:[email protected]> wrote:
+1 for “OAuth 2.0 Authorization Server Discovery”
//Samuel
On Thu, Feb 25, 2016 at 8:10 PM, Mike Jones
<[email protected]<mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>> wrote:
Thanks for your thoughts, Vladimir. I’m increasingly inclined to accept your
suggestion to change the title from “OAuth 2.0 Discovery” to “OAuth 2.0
Authorization Server Discovery”. While the abstract already makes it clear
that the scope of the document is AS discovery, doing so in the title seems
like it could help clarify things, given that a lot of the discussion seems to
be about resource discovery, which is out of scope of the document.
I’m not saying that resource discovery isn’t important – it is – but unlike
authorization server discovery, where there’s lots of existing practice,
including using the existing data format for describing OAuth implementations
that aren’t being used with OpenID Connect, there’s no existing practice to
standardize for resource discovery. The time to create a standard for that
seems to be after existing practice has emerged. It *might* or might not use
new metadata values in the AS discovery document, but that’s still to be
determined. The one reason to leave the title as-is is that resource discovery
might end up involving extensions to this metadata format in some cases.
I think an analogy to the core OAuth documents RFC 6749 and RFC 6750 applies.
6749 is about the AS. 6750 is about the RS. The discovery document is about
the AS. We don’t yet have a specification or existing practice for RS
discovery, which would be the 6750 analogy.
In summary, which title do people prefer?
· “OAuth 2.0 Discovery”
· “OAuth 2.0 Authorization Server Discovery”
-- Mike
<>
From: OAuth [mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]>] On Behalf Of
Vladimir Dzhuvinov
Sent: Thursday, February 25, 2016 12:59 AM
To: [email protected]<mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
In OIDC the discovery doc is of great utility to developers and integrators.
Developers also tend to find it a more accurate and complete description of how
to set up a client for a particular deployment, compared to traditional online
docs, which may be not be up to date, or even missing. Very much like
auto-generated Swagger and JavaDocs.
Here are some example OIDC discovery docs:
https://accounts.google.com/.well-known/openid-configuration
<https://accounts.google.com/.well-known/openid-configuration><https://accounts.google.com/.well-known/openid-configuration>
https://www.paypalobjects.com/.well-known/openid-configuration
<https://www.paypalobjects.com/.well-known/openid-configuration><https://www.paypalobjects.com/.well-known/openid-configuration>
https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration
<https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration><https://login.microsoftonline.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration>
With this discovery document in place setup of identity federation can then be
easily scripted. For example:
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html
<http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html><http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html>
Now, does that dictate any particular app architecture? My reading of the spec
is that it doesn't, and it shouldn't either. By staying neutral on the topics
of RS discovery and registering RPs with RSs. And how one arrives at the
".well-known/...". I'm not even sure that resource discovery should be a topic
of this WG. Perhaps to this end, and to prevent confusion that the spec is
trying to do something more, a more specific title would suit it better. E.g.
"AS Discovery".
Cheers,
Vladimir
On 25/02/16 02:25, Phil Hunt (IDM) wrote:
And so does oracle and so does google. Each different.
So how can an app dictate it then unless we all go to a common architecture?
Phil
On Feb 24, 2016, at 16:04, Mike Jones
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]> wrote:
Azure defines ways for resource servers to be registered for use with a client
and for clients to dynamically request an access token for use at a particular
resource server. You can call that custom architecture if you want. It’s
well-defined but it’s not currently in the standards realm. I know that Google
has syntax for doing the same, as I’m sure do a lot of other cloud OAuth
deployments, such as Oracle’s. For what it’s worth, the working group talked
about possibly producing a standard version of syntax for making these kinds of
requests during our discussions in Prague (during the Token Exchange
discussion) but nobody has run with this yet.
In this sense, yes, Azure is an application of the kind we’re talking about.
Azure already does define specific new OAuth 2.0 discovery metadata values that
are used in production. A registry just doesn’t yet exist in which it can
register those that are of general applicability.
-- Mike
From: Phil Hunt (IDM) [mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]>]
Sent: Wednesday, February 24, 2016 3:52 PM
To: Mike Jones
Cc: <[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
Mike
Take a look at the assumptions you are making.
You seem to be assuming application software dictates oauth infrastructure
architecture by suggesting that apps register in iana.
Would ms azure allow custom arch?
Phil
On Feb 24, 2016, at 15:28, Mike Jones
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]> wrote:
The UserInfo Endpoint path isn’t fixed and so has to be discovered.
I agree that for some OAuth profiles, one or more resource servers will have to
be discovered starting from the authorization server. Working group members
have also described wanting to discover authorization servers starting from
resource servers. There isn’t a standard practice for any of this, which is
why it’s intentionally left out of the current specification.
Once the IANA OAuth Discovery Metadata Registry has been established, which
will happen after the current specification has been approved, it will be easy
for subsequent specifications to document existing practice for different OAuth
profiles and register discovery metadata values supporting them. Some of those
values will likely define ways to discover resource servers, when applicable.
But first, we need to finish the existing spec, so that the registry enabling
these extensions gets established in the first place.
-- Mike
From: Phil Hunt (IDM) [mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]>]
Sent: Wednesday, February 24, 2016 2:13 PM
To: Mike Jones
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
Cc: <[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
Yup. And because there many relations the client mist be able to discover it.
The client does not know if the res server is legit.
The userinfo is always fix and so u dont need discovery.
Phil
On Feb 24, 2016, at 14:05, Mike Jones
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]> wrote:
In OpenID Connect, there’s a resource server called the UserInfo Endpoint that
returns claims about the authenticated user as a JSON data structure. Its
location is published in OpenID Connect discovery metadata as the
“userinfo_endpoint” metadata value, which is defined at
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata
<http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata><http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata>.
We didn’t include the UserInfo Endpoint in the generic OAuth discovery spec
since in OAuth, there are lots of possible relationships between authorization
servers and resource servers and they needn’t be one-to-one, as is being
actively discussed by the working group. For instance, see George Fletcher’s
recent contribution.
Thanks for the good discussion, Phil.
-- Mike
From: Phil Hunt (IDM) [mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]>]
Sent: Wednesday, February 24, 2016 1:25 PM
To: Mike Jones
Cc: <[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
Where is the profile endpoint (oidc's resource server) published? (For the non
OIDC people on the list).
Phil
On Feb 24, 2016, at 13:09, Mike Jones
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]> wrote:
To the extent that generic OAuth 2.0 needs to publish some of the same
information as OpenID Connect – which is built on generic OAuth 2.0 – it makes
sense to publish that information using exactly the same syntax, since that
syntax is already in widespread use. That what this draft accomplishes.
There’s nothing Connect-specific about using metadata response values like:
"authorization_endpoint":
"https://server.example.com/authorize";<https://server.example.com/authorize>
<https://server.example.com/authorize><https://server.example.com/authorize>,
"token_endpoint":
"https://server.example.com/token";<https://server.example.com/token>
<https://server.example.com/token><https://server.example.com/token>,
"token_endpoint_auth_methods_supported": ["client_secret_basic",
"private_key_jwt"],
"registration_endpoint":
"https://server.example.com/register";<https://server.example.com/register>
<https://server.example.com/register><https://server.example.com/register>,
"response_types_supported": ["code", "token"],
"service_documentation":
"http://server.example.com/service_documentation.html";<http://server.example.com/service_documentation.html>
<http://server.example.com/service_documentation.html><http://server.example.com/service_documentation.html>,
Is there a reason that you would like the syntax for any of these or the other
generally applicable OAuth 2.0 metadata values to be different? I don’t see
any good reason for unnecessary differences to be introduced.
-- Mike
From: Phil Hunt (IDM) [mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]>]
Sent: Wednesday, February 24, 2016 12:45 PM
To: Anthony Nadalin <[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
Cc: Mike Jones
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>;
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
Mike
Publishing on dev pages does not work for software (esp open source) that is
deployed both in enterprises and on PaaS cloud providers.
The current draft is may codify current OIDC practice and be appropriate for
oidc but it is not ready for generic oauth. There is no generic oauth
experience at this time.
Phil
On Feb 24, 2016, at 10:25, Anthony Nadalin
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]> wrote:
Sure there is, it is as you have now made it far easier and the security
considerations does not even address this
From: Mike Jones
Sent: Wednesday, February 24, 2016 10:22 AM
To: Anthony Nadalin <[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
Cc: <[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
As we’d discussed in person, there’s no effective security difference between
discovery information being published in an ad-hoc fashion on developer pages
and it being published in a standard format. “Security by obscurity” adds no
real security at all.
-- Mike
From: Anthony Nadalin
Sent: Wednesday, February 24, 2016 10:01 AM
To: Mike Jones
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>; Phil
Hunt (IDM) <[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>; Nat Sakimura
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
Cc: <[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
Subject: RE: [OAUTH-WG] OAuth 2.0 Discovery Location
The point of the WGLC is to finish standardizing the core discovery
functionality that’s already widely deployed.
That may be widely deployed for OIDC but not widely deployed for OAuth. There
are some authentication mechanism discovery for endpoint that really should not
be in an OAuth standard since it’s really not dealt with. Now that all this
information is available it makes poking around the endpoint more focused for
people that want to disrupt your endpoints, that is really not addressed in the
security considerations section at all
From: OAuth [mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]>] On Behalf Of
Mike Jones
Sent: Wednesday, February 24, 2016 9:54 AM
To: Phil Hunt (IDM) <[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>; Nat Sakimura
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
Cc: <[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
The point of the WGLC is to finish standardizing the core discovery
functionality that’s already widely deployed.
None of Nat or John or I are suggesting that additional related functionality
won’t be created. I’m sure it will be. Some applications will use WebFinger
to locate the discovery metadata. Some will possibly use link headers. Some
will possibly use application-specific .well-known values. I’m sure there’s
other things I haven’t even thought about. All of these depend upon having a
discovery metadata document format and none of them change it – other than
possibly to register additional discovery metadata values.
So by all means, the working group should continue discussing inventing
possible new related mechanisms that make sense in some contexts. At the same
time, we can finish standardizing the already widely deployed core
functionality that all of these mechanisms will need.
-- Mike
From: OAuth [mailto:[email protected]
<mailto:[email protected]><mailto:[email protected]>] On Behalf Of
Phil Hunt (IDM)
Sent: Wednesday, February 24, 2016 8:39 AM
To: Nat Sakimura <[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
Cc: <[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
I am suggesting that part of the discovery solution has to be the client
indicating what resource endpoint it wants the oauth configuration data for.
So if res.example.evil.com<http://res.example.evil.com>
<http://res.example.evil.com/><http://res.example.evil.com/> is not a valid
resource endpoint for as.example.com<http://as.example.com>
<http://as.example.com/><http://as.example.com/> the authz discovery should
fail in some way (eg return nothing).
There may be better ways to do this. Eg combine discovery. Or change the order
of discovery.
One of OAuth's strength's and weaknesses is that the target of authorization
(the resource) is never specified. It is often bound up in the client
registration and an often implied 1:1 relationship between resource and as.
Given that in discovery phase registration has not yet occurred it seems
important that the client know it has a valid combination of endpoints etc.
This is why I was disappointed about wglc on discovery. We had a starting point
for group adoption but we haven't really defined the full requirements IMO.
I am on vacation or I would put some thought into some draft changes or a new
draft. I apologize I can't do it now.
Phil
On Feb 24, 2016, at 08:12, Nat Sakimura
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]> wrote:
Hi Phil,
Are you suggesting that the AS metadata should include the RS URIs? Currently,
it does not, but it can be done, I guess.
The way oauth-meta works is that
1. RS tells the client where the AS is.
2. AS tells the client which RS endpoints the token can be used.
Even if there is a bad AS with a valid certs that proxies to the good RS, the
client will not send the token there as the authz server will say that is not
the place the client may want to send the token to.
Nat
2016年2月24日(水) 23:59 Phil Hunt
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>:
Nat,
I’m not sure that having the resource server tell the client where its
authorization server is secure by itself. The relationship between the
Authorization Server and the Resource server need to be bound together in one
of the discovery endpoints (the resource and/or the oauth service discovery).
If a client discovers a fake resource server that is proxying for a real
resource server the current discovery spec will not lead the client to
understand it has the wrong resource server. Rather the fake resource service
will just have a fake discovery service. The hacker can now intercept resource
payload as well as tokens because they were able to convince the client to use
the legit authorization service but use the token against the hackers proxy.
The OAuth Discovery service needs to confirm to the client that the server is
able to issue tokens for a stated resource endpoint.
This not only works in normal OAuth but should add security even to UMA
situations.
Phil
@independentid
www.independentid.com<http://www.independentid.com/>
<http://www.independentid.com/><http://www.independentid.com/>
[email protected]<mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
On Feb 24, 2016, at 3:54 AM, Nat Sakimura
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]> wrote:
Hi Thomas,
inline:
2016年2月22日(月) 18:44 Thomas Broyer
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>:
Couldn't the document only describe the metadata?
I quite like the idea of draft-sakimura-oauth-meta if you really want to do
discovery, and leave it open to implementers / to other specs to define a
.well-known URL for "auto-configuration".
The metadata described here would then either be used as-is, at any URL,
returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for
other metadata specs (like OpenID Connect).
With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of
WWW-Authenticate response header, you have everything you need to proceed
Yup. That's one of the requirements to be RESTful, is it not?
In OAuth's case, the resource and the authorization server are usually tightly
coupled. (Otherwise, you need another specs like UMA.)
So, the resource server should be able to tell either the location of the authz
endpoint. In some trusted environment, the resource may as well return the
location of the authz server configuration data. In these cases, you do not
have to decide on what .well-known uri as you say. This frees up developers
from configuration file location collisions etc. We should strive not to
pollute the uri space as much as possible.
(well, except if there are several ASs each with different scopes; sounds like
an edge-case to me though; maybe RFC6750 should instead be updated with such a
parameter such that an RS could return several WWW-Authenticate: Bearer, each
with its own "scope" and "duri" value?)
Yeah, I guess it is an edge case. I would rather like to see these authz
servers to develop a trust framework under which they can agree on a single set
of common scope parameter values.
Cheers,
Nat
On Fri, Feb 19, 2016 at 10:59 PM Justin Richer
<[email protected]><mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]> wrote:
The newly-trimmed OAuth Discovery document is helpful and moving in the right
direction. It does, however, still have too many vestiges of its OpenID Connect
origins. One issue in particular still really bothers me: the use of
“/.well-known/openid-configuration” in the discovery portion. Is this an OAuth
discovery document, or an OpenID Connect one? There is absolutely no compelling
reason to tie the URL to the OIDC discovery mechanism.
I propose that we use “/.well-known/oauth-authorization-server” as the default
discovery location, and state that the document MAY also be reachable from
“/.well-known/openid-configuration” if the server also provides OpenID Connect
on the same domain. Other applications SHOULD use the same parameter names to
describe OAuth endpoints and functions inside their service-specific discovery
document.
— Justin
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth><https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth><https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth><https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth><https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth><https://www.ietf.org/mailman/listinfo/oauth>
--
Vladimir Dzhuvinov :: [email protected]<mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
<mailto:[email protected]><mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
