Hi Nat, RFC6750 “OAuth 2.0 Bearer Token Usage” section 3 “The WWW-Authenticate Response Header Field” is a start, but it isn’t really suitable. Firstly, it is a Bearer-specific, whereas we need is a way to say “OAuth 2.0 is available” regardless of the type of temporary credentials that get issued. It doesn’t include pointers to he AS, which CPA presumably require as their example includes this (I guess a link header can work, though including auth-specific info in a dedicated auth- header when auth is required but missing sounds like a decent fit).
Curiously, 1 of the 2 example scope values mentioned in RFC6750 section 3 for the WWW-Authenticate header has “openid”, but this is the one values that will never be useful there. scope=openid means the client app wants an id-token; it is pointless for a protected resource (which is the party returning WWW-Authenticate) to ask for it. -- James Manger From: Nat Sakimura [mailto:[email protected]] Sent: Sunday, 15 May 2016 1:38 AM To: Manger, James <[email protected]>; Hannes Tschofenig <[email protected]>; [email protected]; [email protected] Subject: Re: [OAUTH-WG] Cross Platform Authentication - OAuth 2.0 Device Flow - WWW-Authenticate to advertise OAuth 2.0 support Hi James, Does not the section 3 of RFC6750 talk about it? If you are talking about uri parameter that represents the AS, then, yes, I think it is a good idea to have one, though IMHO it is better to be returned in a link header. Best, Nat On Fri, May 13, 2016 at 04:04 Manger, James <[email protected]<mailto:[email protected]>> wrote: Hi Michael & OAuth-ers, The EBU Cross Platform Auth spec has defined their own "CPA" scheme for the WWW-Authenticate HTTP response header to advertise OAuth 2.0 capability [section 7.7.1 "Authentication challenge" in https://tech.ebu.ch/docs/tech/tech3366.pdf]. WWW-Authenticate: CPA version="1.0" name="Example Authorization Provider" uri="https://ap.example.com/cpa"; modes="client,user" It is a shame that there isn’t a standard OAuth way to do this without needing a CPA-specific scheme. P.S. This CPA example is invalid. It needs commas between attributes [https://tools.ietf.org/html/rfc7235#appendix-C]. -- James Manger -----Original Message----- From: OAuth [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Hannes Tschofenig Sent: Wednesday, 11 May 2016 8:48 PM To: [email protected]<mailto:[email protected]> Subject: [OAUTH-WG] OAuth 2.0 for broadcasters Hi all, End of April I had the chance to talk to Michael Barroco (from the European Broadcasting Union) and to Chris Needham (from the BBC) regarding their use of OAuth 2.0 for broadcasters. In March Michael dropped a mail to the OAuth mailing list to make us aware of their work, see https://www.ietf.org/mail-archive/web/oauth/current/msg15969.html The specification they are working on is based on the OAuth Device flow. Michael and Chris walked me through a slide deck offering me more background regarding their work. (I will upload the slide deck to our Wiki but the IETF meeting site seems to be down at the moment.) In addition to the specification code and tutorials have been developed and you can find them here: https://github.com/ebu/cpa-tutorial https://tech.ebu.ch/code I gave Chris & Michael an update of what we are doing in the OAuth working group since I believe some of our currently chartered items could be relevant for them, such as the native apps BCP or the PoP/Token Binding work. I also mentioned that we are looking for feedback from their group on the Device Flow specification. Ciao Hannes From: "Barroco, Michael" <barroco at ebu.ch<http://ebu.ch>> To: "oauth at ietf.org<http://ietf.org>" <oauth at ietf.org<http://ietf.org>> Cc: "tvp-cpa at list.ebu.ch<http://list.ebu.ch>" <tvp-cpa at list.ebu.ch<http://list.ebu.ch>> Date: Mon, 7 Mar 2016 08:43:56 +0000 Dear all, We are contacting you because we noticed that you recently restarted the work on OAuth 2.0 Device Flow. We are in the process of publishing an ETSI standard [1] specifying a protocol with very similar goals. This has been developed by an EBU (European Broadcasting Union) working group involving broadcasters, such as BBC, SRG-RTS, VRT, RTVE, TVP, Global Radio UK, and device manufacturers. Our work on the “Cross Platform Authentication” protocol targets media devices, such as connected TVs and radio receivers. It is based on the early OAuth 2.0 Device Flow draft, but includes additional features driven by broadcast industry requirements. These include: dynamic registration of clients, dynamic discovery of the authorization provider, and issuing of access tokens without requiring association with a user account in order to provide device-based authentication that does not require user sign-in or pairing. Our draft protocol specification is available here [2]. Cross Platform Authentication also specifies several aspects left open to implementers in OAuth 2.0, such as endpoint URL paths, to facilitate interoperability. Also note that reference implementations are available [3]. We would be very interested in working together with you to explain our design requirements and try to align our protocol designs. With best regards, The EBU Cross Platform Authentication group https://tech.ebu.ch/cpa [1] https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=47970 [2] https://tech.ebu.ch/docs/tech/tech3366.pdf [3] https://tech.ebu.ch/code/cpa ------------------------------------------------------------------------------ _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura Chairman of the Board, OpenID Foundation Trustee, Kantara Initiative
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
