[OAUTH-WG] OAuth Security Workshop -- July 14th and 15th 2016 in Trier/Germany

[Hannes Tschofenig]

Hi all,

early this year we announced our plans to organize an OAuth security
workshop. In the meanwhile we have made progress in the planning
activities and we are happy to announce that the workshop will take
place July 14th and 15th 2016 in Trier/Germany. The date fits nicely
with the IETF meeting in Berlin and our host, the Chair for Information
Security and Cryptography at the University of Trier, may be familiar to
some of you in context of the formal security analysis of OAuth also
published earlier this year.

More information can be found here:
https://infsec.uni-trier.de/events/osw2016

With this workshop we particularly encourage researchers and other
security experts to analyse OAuth and OAuth extensions and to report
their findings at this workshop. Please note the position paper
deadline, which is May 21st.

We are looking forward to your contributions and to the discussions at
the workshop! Feel free to contact us if there are questions.

Ciao
Hannes & Derek



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

[Phil Hunt]

Step 0 is  something we need to discuss. 

An OAuth protected resource can be hacked if a client uses an evil discovery 
and it returns a proxied resource server.  Just as a token server can be 
proxied, so can a resource server.  So the OAuth server may be issuing tokens 
in a secure way, but then it gives it to a client that uses them at the wrong 
endpoint.

I believe the resource and the As must be bound together in a security 
relationship. The security descriptor needs to reflect this.

I am ok with separate app data discovery.  But from the oauth security 
perspective, the oauth server needs to indicate that it is the correct server 
to use for Rx.

There are probably multiple ways to do this, but I think the discovery draft 
has only addressed 2 of 3 endpoints.  We need all of them bound together.

@independentid
www.independentid.com phil.h...@oracle.com 






> On Feb 18, 2016, at 11:30 PM, Nat Sakimura  wrote:
> 
> 
> 
> 2016年2月19日(金) 14:58 Phil Hunt (IDM)  >:
> Inline...
> 
> Phil
> 
> On Feb 18, 2016, at 22:19, Nat Sakimura  > wrote:
> 
>> Thanks for the explanation. Let me re-formulate.  <>
>>  
>> 
>> Assumption
>> 
> 
> 
>> 1. There are resource server – authorization server pairs: R1A1 … RnAn. 
>> 
>> 2. There are clients C1 … Cm. 
>> 
>> 3. These instances can be hosted on a multi-tenancy environment. 
>> 
>>  
>> 
>> Flow
>> 
> 
> Step 0. The client discovers the resource server endpoint and its configs. 
> 
> Sure, but that's out of scope, is it not? If I am not mistaken, we are 
> talking about OAuth server configuration discovery. I do agree that resource 
> discovery in itself is a very interesting and important work which I would 
> love to work on, but that is not what we are talking about here, I think.  
>  
> Question: should that include oauth?? John seems to imply yes. 
> 
> I do not think so. I think he was referring to the configuration of Ay that 
> corresponds to Ry. John?  
>> 1. Client Cx goes to a resource server Ry, but he was denied of the 
>> access and was told to get an access token. Now Cx needs to know where to 
>> go. 
>> 
>> 2. Cx uses << Discovery>> to find the OAuth endpoints and the associated 
>> metadata on Ay that corresponds to Ry. 
>> 
> 
> Where is the discovery for Ay?
> I was just trying to understand your use case. I have not put any solution 
> into it. That's why I marked discovery as <>.  
> 
> The default one that the draft suggest is the https://authority 
> (uri(Ay))/.well-known/openid-configuration. 
> What John is suggesting is that we could also have 
> https://authority(uri(Ay))/.well-known/oauth-config-for-Ry 
> , if I read his 
> message correctly. 
> 
> 
>> 3. Cx goes and fetches the Discovery file. 
>> 
>> 4. Cx goes to Ay to get authorized using the config info in the 
>> Discovery file and the rest is normal RFC6749. 
>> 
> 
> Referring to the risk that a client discovered from a bad source (eg to 
> insert a fake token endpoint), how does Ay know what discovery the client 
> used was correct?  This might not be a problem in reality but it needs to 
> work. 
> 
> Right. We are currently asking the clients to be sane enough to get the 
> configuration for the server directly over https at the authorization server, 
> more or less. When Ay gets an authorization request, it has no way of knowing 
> that the client got the config from the right endpoint. Are you suggesting 
> something like have the client send the signature of the config file that it 
> is using now? 
>>  
>> 
>> Is this correct? 
>> 
>>  
>> 
>> Nat
>> 
>>  
>> 
>> --
>> 
>> PLEASE READ :This e-mail is confidential and intended for the
>> 
>> named recipient only. If you are not an intended recipient,
>> 
>> please notify the sender  and delete this e-mail.
>> 
>>  
>> 
>> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com 
>> ] 
>> Sent: Friday, February 19, 2016 1:58 PM
>> To: Nat Sakimura
>> Cc: Mike Jones; oauth@ietf.org 
>> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
>> 
>>  
>> 
>> No. Much simpler. 
>> 
>>  
>> 
>> A service provider has decided to have a separate oauth server for each web 
>> 'property'. This could be because they were acquired separately and run 
>> different infrastructures. Or the business structure keeps each BU 
>> completely separate. 
>> 
>>  
>> 
>> The client can't really depend on previously known or hard coded endpoints 
>> because there are 1000s of instances deployed (eg as in tenancies). 
>> 
>>  
>> 
>> This dynamic discovery is going to be particularly true of open source 
>> software that customers choose to host on PaaS cloud providers of their 
>> choosing. 
>> 
>> 
>> Phil
>> 
>> 
>> On Feb 18, 2016, at 19:04, Nat Sakimura >

Re: [OAUTH-WG] OAuth Security Workshop -- July 14th and 15th 2016 in Trier/Germany

[Phil Hunt]

Thanks Hannes.  That’s great news!

Phil

@independentid
www.independentid.com phil.h...@oracle.com 






> On Feb 19, 2016, at 3:12 AM, Hannes Tschofenig  
> wrote:
> 
> Hi all,
> 
> early this year we announced our plans to organize an OAuth security
> workshop. In the meanwhile we have made progress in the planning
> activities and we are happy to announce that the workshop will take
> place July 14th and 15th 2016 in Trier/Germany. The date fits nicely
> with the IETF meeting in Berlin and our host, the Chair for Information
> Security and Cryptography at the University of Trier, may be familiar to
> some of you in context of the formal security analysis of OAuth also
> published earlier this year.
> 
> More information can be found here:
> https://infsec.uni-trier.de/events/osw2016
> 
> With this workshop we particularly encourage researchers and other
> security experts to analyse OAuth and OAuth extensions and to report
> their findings at this workshop. Please note the position paper
> deadline, which is May 21st.
> 
> We are looking forward to your contributions and to the discussions at
> the workshop! Feel free to contact us if there are questions.
> 
> Ciao
> Hannes & Derek
> 
> ___
> 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-WG] RFC 7009: Revoke Access Tokens issued to HTML5 web apps

[Thomas.Kupka]

Hi,

we use the OAuth 2.0 Implicit grant to issue access_tokens to client 
applications such as HTML 5 web apps that have no secure means to securely 
authenticating themselves. Even if the credentials would be obfuscated, any 
user could extract them from the HTTP requests their User Agent makes with 
minimal effort. Since RFC 7009 also talks about the usage of CORS to support 
User-Agent clients, however, I believe that these clients should be supported.

So I am having trouble supporting the revocation requirement in RFC 7009 which 
states:



   The client also includes its authentication credentials as described

   in Section 2.3. of 
[RFC6749].

Looking at said section in in RFC 6749, it states:


   If the client type is confidential, the client and authorization

   server establish a client authentication method suitable for the

   security requirements of the authorization server.  The authorization

   server MAY accept any form of client authentication meeting its

   security requirements.

I am unsure whether "having no form of client authentication" conforms to the 
standard, can you comment on this?

As a side note, I wonder why client authentication for token revocations is 
required anyway, because if a client received a token by any legit means, it 
should always be able to revoke it, regardless of authentication. And if an 
unauthorized client 'stole' any type of token, revoking it should also be 
possible, since loss of service for the intended client should always be 
preferred over misusing the token.

Cheers,

Thomas


BMW Group
Thomas Kupka
Customer Data Management, FG-6301
GCDM Identity & Access Management
Bremer Straße 6
80807 München

Postanschrift:
80788 München

Tel: +49-89-382-54083
Mail: thomas.ku...@bmw.de
Web:  http://www.bmwgroup.com/

Bayerische Motoren Werke Aktiengesellschaft
Vorstand: Harald Krüger (Vorsitzender),
Milagros Caiña Carreiro-Andree, Klaus Draeger,
Friedrich Eichiner, Klaus Fröhlich, Ian Robertson,
Peter Schwarzenbauer, Oliver Zipse.
Vorsitzender des Aufsichtsrats: Norbert Reithofer
Sitz und Registergericht: München HRB 42243


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

[Hannes Tschofenig]

Early February I posted a mail to the list to make progress on the
solution to the OAuth Authorization Server Mix-Up problem discovered
late last year.

Here is my mail about the Authorization Server Mix-Up:
http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html

Here is my mail to the list that tries to summarize the discussion
status and asked a few questions:
http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html

Unfortunately, my mail didn't lead to the intended success. While there
was some feedback I wasn't getting the desired response.

In order to move forward I believe we need a working group document that
serves as a starting point for further work in the group*. We have two
documents that provide similar functionality in an attempt to solve the
Authorization Server Mix-Up problem.

So, here is the question for the group. Which document do you want as a
starting point for work on this topic:

-- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley

Link:
https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01

-- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and
Sascha Preibisch

Link:
https://tools.ietf.org/html/draft-sakimura-oauth-meta-07

Deadline for feedback is March, 4th.

Ciao
Hannes & Derek

PS: (*) Regardless of the selected solution we will provide proper
acknowledgement for those who contributed to the work.



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

[Mike Jones]

Option A.  I have higher confidence that this specification solves the problems 
because it was designed during a 4-day security meeting dedicated to this task 
by a group of over 20 OAuth security experts, including both sets of 
researchers in Germany who originally identified the problem.  This solution 
has also been implemented and interop tested by Roland Hedberg, Brian Campbell, 
and I believe others.  Note that the reason I am advocating this specification 
is *not* because I'm an editor of it; my role was to record in spec language 
what the OAuth security experts designed together over the 4-day period in 
Darmstadt.



I’ll also note that even if Option B also solves the problem, it comes at 
significant adoption costs and complexity not found in A.  In particular, it 
requires that developers understand support a new “Link Relation” syntax not 
used elsewhere in OAuth.  As Nat writes about his own draft in 
http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html - there is not 
a standard JSON syntax for link relations.  He writes “we could easily create a 
parallel to it”.  I’d rather we solve the problem using standard mechanisms 
already employed in OAuth, rather than risk bifurcating OAuth in the developer 
community by unnecessarily inventing/creating new syntax that is unfamiliar to 
developers and that many of them may reject using.



  -- Mike



P.S.  Information about the OAuth security meeting can be found at 
https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit
 and 
https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5NtakVbA_sk/edit
 .



-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Friday, February 19, 2016 11:43 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption



Early February I posted a mail to the list to make progress on the solution to 
the OAuth Authorization Server Mix-Up problem discovered late last year.



Here is my mail about the Authorization Server Mix-Up:

http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html



Here is my mail to the list that tries to summarize the discussion status and 
asked a few questions:

http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html



Unfortunately, my mail didn't lead to the intended success. While there was 
some feedback I wasn't getting the desired response.



In order to move forward I believe we need a working group document that serves 
as a starting point for further work in the group*. We have two documents that 
provide similar functionality in an attempt to solve the Authorization Server 
Mix-Up problem.



So, here is the question for the group. Which document do you want as a 
starting point for work on this topic:



-- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley



Link:

https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01



-- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and Sascha 
Preibisch



Link:

https://tools.ietf.org/html/draft-sakimura-oauth-meta-07



Deadline for feedback is March, 4th.



Ciao

Hannes & Derek



PS: (*) Regardless of the selected solution we will provide proper 
acknowledgement for those who contributed to the work.


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

[Hans Zandbelt]

Option A: I agree with Mike that the complexity and implementation cost 
of Option B will make adoption harder, which was also a concern with the 
first iteration of Option A.


To be honest, I'm not sure most people would even understand why the 
complexity would be required and just forget about it. At least with the 
simplicity of the most recent option A they don't have to care, just add 
some simple parameters/checks.


And for the record: I've also implemented option A in the 
mod_auth_openidc [1] and lua-resty-openidc [2] clients for Apache and 
NGINX respectively.


Hans.

[1] https://github.com/pingidentity/mod_auth_openidc
[2] https://github.com/pingidentity/lua-resty-openidc

On 2/19/16 9:18 PM, Mike Jones wrote:

Option A.  I have higher confidence that this specification solves the
problems because it was designed during a 4-day security meeting
dedicated to this task by a group of over 20 OAuth security experts,
*including both sets of researchers in Germany who originally identified
the problem*.  This solution has also been implemented and interop
tested by Roland Hedberg, Brian Campbell, and I believe others.  Note
that the reason I am advocating this specification is **not** because
I'm an editor of it; my role was to record in spec language what the
OAuth security experts designed together over the 4-day period in Darmstadt.

I’ll also note that even if Option B also solves the problem, it comes
at significant adoption costs and complexity not found in A.  In
particular, it requires that developers understand support a new “Link
Relation” syntax not used elsewhere in OAuth.  As Nat writes about his
own draft in
http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html - there
is not a standard JSON syntax for link relations.  He writes “we could
easily create a parallel to it”.  I’d rather we solve the problem using
standard mechanisms already employed in OAuth, rather than risk
bifurcating OAuth in the developer community by unnecessarily
inventing/creating new syntax that is unfamiliar to developers and that
many of them may reject using.

   -- Mike

P.S.  Information about the OAuth security meeting can be found at
https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit
and
https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5NtakVbA_sk/edit
.

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Friday, February 19, 2016 11:43 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for
Adoption

Early February I posted a mail to the list to make progress on the
solution to the OAuth Authorization Server Mix-Up problem discovered
late last year.

Here is my mail about the Authorization Server Mix-Up:

http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html

Here is my mail to the list that tries to summarize the discussion
status and asked a few questions:

http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html

Unfortunately, my mail didn't lead to the intended success. While there
was some feedback I wasn't getting the desired response.

In order to move forward I believe we need a working group document that
serves as a starting point for further work in the group*. We have two
documents that provide similar functionality in an attempt to solve the
Authorization Server Mix-Up problem.

So, here is the question for the group. Which document do you want as a
starting point for work on this topic:

-- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley

Link:

https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01

-- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and
Sascha Preibisch

Link:

https://tools.ietf.org/html/draft-sakimura-oauth-meta-07

Deadline for feedback is March, 4th.

Ciao

Hannes & Derek

PS: (*) Regardless of the selected solution we will provide proper
acknowledgement for those who contributed to the work.



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
Hans Zandbelt  | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth 2.0 Discovery Location

[Justin Richer]

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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[Vladimir Dzhuvinov]

+1

On 19/02/16 23:59, Justin Richer 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth




smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

[Phil Hunt (IDM)]

Option A

Phil

> On Feb 19, 2016, at 13:39, Hans Zandbelt  wrote:
> 
> Option A: I agree with Mike that the complexity and implementation cost of 
> Option B will make adoption harder, which was also a concern with the first 
> iteration of Option A.
> 
> To be honest, I'm not sure most people would even understand why the 
> complexity would be required and just forget about it. At least with the 
> simplicity of the most recent option A they don't have to care, just add some 
> simple parameters/checks.
> 
> And for the record: I've also implemented option A in the mod_auth_openidc 
> [1] and lua-resty-openidc [2] clients for Apache and NGINX respectively.
> 
> Hans.
> 
> [1] https://github.com/pingidentity/mod_auth_openidc
> [2] https://github.com/pingidentity/lua-resty-openidc
> 
>> On 2/19/16 9:18 PM, Mike Jones wrote:
>> Option A.  I have higher confidence that this specification solves the
>> problems because it was designed during a 4-day security meeting
>> dedicated to this task by a group of over 20 OAuth security experts,
>> *including both sets of researchers in Germany who originally identified
>> the problem*.  This solution has also been implemented and interop
>> tested by Roland Hedberg, Brian Campbell, and I believe others.  Note
>> that the reason I am advocating this specification is **not** because
>> I'm an editor of it; my role was to record in spec language what the
>> OAuth security experts designed together over the 4-day period in Darmstadt.
>> 
>> I’ll also note that even if Option B also solves the problem, it comes
>> at significant adoption costs and complexity not found in A.  In
>> particular, it requires that developers understand support a new “Link
>> Relation” syntax not used elsewhere in OAuth.  As Nat writes about his
>> own draft in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html - there
>> is not a standard JSON syntax for link relations.  He writes “we could
>> easily create a parallel to it”.  I’d rather we solve the problem using
>> standard mechanisms already employed in OAuth, rather than risk
>> bifurcating OAuth in the developer community by unnecessarily
>> inventing/creating new syntax that is unfamiliar to developers and that
>> many of them may reject using.
>> 
>>   -- Mike
>> 
>> P.S.  Information about the OAuth security meeting can be found at
>> https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit
>> and
>> https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5NtakVbA_sk/edit
>> .
>> 
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Friday, February 19, 2016 11:43 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for
>> Adoption
>> 
>> Early February I posted a mail to the list to make progress on the
>> solution to the OAuth Authorization Server Mix-Up problem discovered
>> late last year.
>> 
>> Here is my mail about the Authorization Server Mix-Up:
>> 
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html
>> 
>> Here is my mail to the list that tries to summarize the discussion
>> status and asked a few questions:
>> 
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html
>> 
>> Unfortunately, my mail didn't lead to the intended success. While there
>> was some feedback I wasn't getting the desired response.
>> 
>> In order to move forward I believe we need a working group document that
>> serves as a starting point for further work in the group*. We have two
>> documents that provide similar functionality in an attempt to solve the
>> Authorization Server Mix-Up problem.
>> 
>> So, here is the question for the group. Which document do you want as a
>> starting point for work on this topic:
>> 
>> -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley
>> 
>> Link:
>> 
>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01
>> 
>> -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and
>> Sascha Preibisch
>> 
>> Link:
>> 
>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07
>> 
>> Deadline for feedback is March, 4th.
>> 
>> Ciao
>> 
>> Hannes & Derek
>> 
>> PS: (*) Regardless of the selected solution we will provide proper
>> acknowledgement for those who contributed to the work.
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> -- 
> Hans Zandbelt  | Sr. Technical Architect
> hzandb...@pingidentity.com | Ping Identity
> 
> ___
> 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