Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B121A02F1 for ; Sun, 13 Dec 2015 12:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9rQkRrQcn0g for ; Sun, 13 Dec 2015 12:50:26 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012D21A0040 for ; Sun, 13 Dec 2015 12:50:25 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tBDKoNxF023607 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 Dec 2015 20:50:23 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tBDKoNbQ029314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 13 Dec 2015 20:50:23 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tBDKoL8K005641; Sun, 13 Dec 2015 20:50:22 GMT Received: from [10.20.218.152] (/204.239.250.1) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 13 Dec 2015 12:50:21 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-497688CC-6A53-4CCB-8956-379E164F97B1 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (13C75) In-Reply-To: <566DD856.1010603@lodderstedt.net> Date: Sun, 13 Dec 2015 12:50:18 -0800 Content-Transfer-Encoding: 7bit Message-Id: <36ECADAA-7A6F-43D5-9429-A7BDAFA0CCAC@oracle.com> References: <566DD856.1010603@lodderstedt.net> To: Torsten Lodderstedt X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 20:50:29 -0000 --Apple-Mail-497688CC-6A53-4CCB-8956-379E164F97B1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1. Good observation.=20 Phil > On Dec 13, 2015, at 12:43, Torsten Lodderstedt w= rote: >=20 > Hi Mike, Nat, John, >=20 > thanks for starting this work.=20 >=20 > It seems you assume the AS can always be discoverd using the user id of th= e resource owner. I think the underlying assumption is resource servers acce= pt access token of different (any?) user specific AS (and OP)? =46rom my per= spective, RSs nowadays typically trust _the_ AS of their security domain/eco= system and all resource owners need to have an user account with this partic= ular AS. So I would assume the process to start at the RS. We potentially ne= ed to cover for both cases.=20 >=20 > What do you think? >=20 > best regards, > Torsten. >=20 >> Am 26.11.2015 um 00:37 schrieb Mike Jones: >> I=E2=80=99m pleased to announce that Nat Sakimura, John Bradley, and I ha= ve created an OAuth 2.0 Discovery specification. This fills a hole in the c= urrent OAuth specification set that is necessary to achieve interoperability= . Indeed, the Interoperability section of OAuth 2.0 states: >> In addition, this specification leaves a few required components partiall= y or fully undefined (e.g., client registration, authorization server capabi= lities, endpoint discovery). Without these components, clients must be manu= ally and specifically configured against a specific authorization server and= resource server in order to interoperate. >> =20 >> This framework was designed with the clear expectation that future work w= ill define prescriptive profiles and extensions necessary to achieve full we= b-scale interoperability. >> =20 >> This specification enables discovery of both endpoint locations and autho= rization server capabilities. >> =20 >> This specification is based upon the already widely deployed OpenID Conne= ct Discovery 1.0 specification and is compatible with it, by design. The OA= uth Discovery spec removes the portions of OpenID Connect Discovery that are= OpenID specific and adds metadata values for Revocation and Introspection e= ndpoints. It also maps OpenID concepts, such as OpenID Provider, Relying Pa= rty, End-User, and Issuer to their OAuth underpinnings, respectively Authori= zation Server, Client, Resource Owner, and the newly introduced Configuratio= n Information Location. Some identifiers with names that appear to be OpenI= D specific were retained for compatibility purposes; despite the reuse of th= ese identifiers that appear to be OpenID specific, their usage in this speci= fication is actually referring to general OAuth 2.0 features that are not sp= ecific to OpenID Connect. >> =20 >> The specification is available at: >> =C2=B7 http://tools.ietf.org/html/draft-jones-oauth-discovery-00 >> =20 >> An HTML-formatted version is also available at: >> =C2=B7 http://self-issued.info/docs/draft-jones-oauth-discovery-0= 0.html >> =20 >> -- Mike >> =20 >> P.S. This note was also posted at http://self-issued.info/?p=3D1496 and a= s @selfissued. >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-497688CC-6A53-4CCB-8956-379E164F97B1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1. Good observation. 

Phil

On Dec 13, 2015, at 12:43, T= orsten Lodderstedt <torsten@lo= dderstedt.net> wrote:

=20 =20 =20 Hi Mike, Nat, John,

thanks for starting this work.

It seems you assume the AS can always be discoverd using the user id of the resource owner. I think the underlying assumption is resource servers accept access token of different (any?) user specific AS (and OP)? =46rom my perspective, RSs nowadays typically trust _the_ AS of their security domain/ecosystem and all resource owners need to have an user account with this particular AS. So I would assume the process to start at the RS. We potentially need to cover for both cases.

What do you think?

best regards,
Torsten.

Am 26.11.2015 um 00:37 schrieb Mike Jones:

I=E2=80=99m pleased to announce that Nat Saki= mura, 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 states:

In addition, this specification leaves a f=
ew required components partially or fully undefined (e.g., client registrati=
on, authorization server capabilities, endpoint discovery).  Without th=
ese components, clients must be manually and specifically configured against=
 a specific authorization server and resource server in order to interoperat=
e.
 
This framework was designed with the clear=
 expectation that future work will define prescriptive profiles and extensio=
ns 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 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, suc=
h
            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:

        
=C2=B7     &=
nbsp;  
              http://tools.ietf.org/html/draft-jon=
es-oauth-discovery-00

        
 
        
An HTML-formatted version
            is also available at:

        
=C2=B7     &=
nbsp;  
              http:=
//self-issued.info/docs/draft-jones-oauth-discovery-00.html

        
 
        
    &nb=
sp;          
                      &nbs=
p;            &n=
bsp;            =
            -- Mike

        
 
        
P.S.  This note was al=
so
            posted at 
              http://self-issued.info/?p=3D1496 and as 
              @selfissued.

      


_______________________________________________
OAuth mailing list
OAuth@i=
etf.org
https://www.ietf.org/mailman/listinfo/oauth

=20
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-497688CC-6A53-4CCB-8956-379E164F97B1--