Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

Josh, Phil Just saying BlueButton is not enough. You need to be a bit more specific since (a) not everyone is familiar with the details of the BlueButton project and (b) we are only interested in a small subset of the work (namely the dynamic client registration parts) and there only a small pa

[OAUTH-WG] Dynamic Client Registration Requirements

Here are some of our requirements for Dynamic Client Registration as we work through the various proposals: 1. Stateless server 2. Code flow support 3. Implicit flow support 4. Multi-tenant support (single endpoint, multiple services) 5. internationalization 6. simple provisioning schema with sc

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

The registration_jwt captures many of the same things that the proposed "software statement" does, and it's presented as an initial access token. The Provider then parses this token and uses the BB+ Discovery system to validate the token against the Registry that issued it. This is what we talk

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

Hi Phil, Using dyn-reg-14 vocabulary: the BB+ `registration_jwt` is an "initial access token" that's used to perform a "Protected Registration" (see B.2of dyn-reg-14). Does this make sense? (Happy to provide more detail if it

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

Josh, I think BlueButton is an important example of use. Tell us more about registration_jwt (which is not part of dyn reg). Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-08-20, at 8:30 AM, Josh Mandel wrote: > The group may be interested in bits of the followi

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

The group may be interested in bits of the following classification that we put together for BlueButton+: http://blue-button.github.io/blue-button-plus-pull/#client-types Here, we classified apps according to 1. whether they can protect a `client_secret` and 2. whether they can protect a `regist

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

By taxonomy i mean the distinct types of clients and associations. Eg - javascript - native app - web app - apps that associate to one endpoint vs those the register with multiple based on events - perm vs temporary associations There are probably more. As Torsten mentions one of the most im

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

Hi Phil, > I think we should start by reviewing use cases taxonomy. What do you mean by "use cases taxonomy"? What exactly would we discuss under that item? > > Then a discussion on any client_id assumptions and actual requirements > for each client case. Why is registration needed for each

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

Hi Eve, Thanks for pointing to this document. I took a brief look at the use case section and also followed the link to the original UMA use case page at http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+Cases The problem with the write-up is that it does not help us in

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

+1 The chosen solution should account for this. Phil On 2013-08-20, at 2:34, Torsten Lodderstedt wrote: > Hi Phil, > > I agree, the client may also present a client_id obtained from another > "source". But: the AS must be able to associate a policy with this particular > id. This typicall

Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

Hi Phil, I agree, the client may also present a client_id obtained from another "source". But: the AS must be able to associate a policy with this particular id. This typically requires a provisioning of the client id before the actual OAuth interaction takes place. Otherwise the AS does not ha