+1
[quote]
> 
> I would like to understand these broader requirements, use cases, and 
> security considerations first. 
> 
> 
> 
> Phil
> 

[\quote]


OAuth is being used in a *much* broader set of use-cases and contexts than 
OpenID connect. 

I think its very important to have a solution that addresses these flows. 

- prateek


> On Nov 27, 2015, at 20:05, Mike Jones <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>> It allows non-Connect implementation of OAuth 2.0 to also have a standard 
>> discovery capability – and one that can later be updated to also support 
>> OpenID Connect with no breaking changes, should that be desired in the 
>> future.
>>  
>>                                                           -- Mike
>>   <>
>> From: Bill Mills [mailto:[email protected] 
>> <mailto:[email protected]>] 
>> Sent: Friday, November 27, 2015 7:58 PM
>> To: Mike Jones <[email protected] 
>> <mailto:[email protected]>>; [email protected] <mailto:[email protected]>
>> Subject: Re: [OAUTH-WG] OAuth Discovery
>>  
>> Can you elaborate on the advantage of having a separate parallel spec to 
>> OpenID Discovery?
>>  
>>  
>> 
>> On Wednesday, November 25, 2015 3:37 PM, Mike Jones 
>> <[email protected] <mailto:[email protected]>> wrote:
>>  
>> 
>> I’m pleased to announce that Nat Sakimura, John Bradley, and I have created 
>> an OAuth 2.0 Discovery specification.  This fills a hole in the current 
>> OAuth specification set that is necessary to achieve interoperability.  
>> Indeed, the Interoperability section of OAuth 2.0  
>> <https://tools.ietf.org/html/rfc6749#section-1.8>states:
>> In addition, this specification leaves a few required components partially 
>> or fully undefined (e.g., client registration, authorization server 
>> capabilities, endpoint discovery).  Without these components, clients must 
>> be manually and specifically configured against a specific authorization 
>> server and resource server in order to interoperate.
>>   
>> This framework was designed with the clear expectation that future work will 
>> define prescriptive profiles and extensions necessary to achieve full 
>> web-scale interoperability.
>>  
>> This specification enables discovery of both endpoint locations and 
>> authorization server capabilities.
>>  
>> This specification is based upon the already widely deployed OpenID Connect 
>> Discovery 1.0 <http://openid.net/specs/openid-connect-discovery-1_0.html> 
>> specification and is compatible with it, by design.  The OAuth Discovery 
>> spec removes the portions of OpenID Connect Discovery that are OpenID 
>> specific and adds metadata values for Revocation and Introspection 
>> endpoints.  It also maps OpenID concepts, such as OpenID Provider, Relying 
>> Party, End-User, and Issuer to their OAuth underpinnings, respectively 
>> Authorization Server, Client, Resource Owner, and the newly introduced 
>> Configuration Information Location.  Some identifiers with names that appear 
>> to be OpenID specific were retained for compatibility purposes; despite the 
>> reuse of these identifiers that appear to be OpenID specific, their usage in 
>> this specification is actually referring to general OAuth 2.0 features that 
>> are not specific to OpenID Connect.
>>  
>> The specification is available at:
>> ·         http://tools.ietf.org/html/draft-jones-oauth-discovery-00 
>> <http://tools.ietf.org/html/draft-jones-oauth-discovery-00>
>>  
>> An HTML-formatted version is also available at:
>> ·         http://self-issued.info/docs/draft-jones-oauth-discovery-00.html 
>> <http://self-issued.info/docs/draft-jones-oauth-discovery-00.html>
>>  
>>                                                                 -- Mike
>>  
>> P.S.  This note was also posted at http://self-issued.info/?p=1496 
>> <http://self-issued.info/?p=1496> and as @selfissued 
>> <https://twitter.com/selfissued>.
>> 
>> _______________________________________________
>> OAuth mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/oauth 
>> <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> _______________________________________________
>> OAuth mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/oauth 
>> <https://www.ietf.org/mailman/listinfo/oauth>
> _______________________________________________
> OAuth mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/oauth 
> <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to