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

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 19 Aug 2013 00:01:02 +0200

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Based on your feedback via the poll let us start with August 22nd with the first conference call. I will distribute the conference call details on Tuesday. 

Let us talk about the agenda. There were several items brought up in discussions, namely 

* Software assertions / software statements

We briefly discussed this topic at the IETF OAuth session but we may need more time to understand the implications for the current dynamic client registration document: 
http://www.ietf.org/proceedings/87/slides/slides-87-oauth-2.pptx

* SCIM vs. current dynamic client registration approach for interacting with the client configuration endpoint

In the past we said that it would be fine to have a profile defined in SCIM to provide the dynamic client registration for those who implement SCIM and want to manage clients also using SCIM. It might, however, be useful to compare the two approaches in detail to see what the differences are. 

* Interactions with the client registration endpoint 

Justin added some "life cycle" description to the document to motivate some of the design decisions. Maybe we need to discuss those in more detail and add further text. 
Additional text could come from the NIST Blue Button / Green Button usage. 

* Aspects that allow servers to store less / no state

- - From the discussions on the list it was not clear whether this is actually accomplishable with the current version of OAuth. We could explore this new requirement and try to get a better understanding how much this relates to dynamic client registration and to what extend it requires changes to the core spec. 

What would you like to start with? Other topics you would like to bring up? 
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJSEULvAAoJEGhJURNOOiAtttEH/Aogg8Q/R/L9/mzU05IQbnze
AdXB1ZvySkV3jZT4I5shmP7hQr6mc6P6UdvyOrSjrvPlBHen55/oa5z7Cwchd1dk
dcDUEavbodjnm9SrOs0nKaTvdeZimFSBkGMrfhoTYLXpymP24F9PZgwUXdOcFocF
OiCs3qDajYaA395DCg5+4mOLQQgDnmy4drlgj2NPv1nMBRDBubzgAhJccwF2BLN9
IW7MAwTEu7vYT/gwIFzriPkui7gYpf8sAqsnzf/z7FtXbsP8imgOKUlQxzZzeSSP
QEb6+syyMD9Gt6wxQfWzyl5T0bYLP6DQ+ldZR8yGKCwb+2k3LN6Q8bIpj4mIERI=
=tkGT
- -----END PGP SIGNATURE-----

---

From: Phil Hunt <[email-masked]>
Date: Sun, 18 Aug 2013 17:15:58 -0700

I think we should start by reviewing use cases taxonomy. 

Then a discussion on any client_id assumptions and actual requirements for each client case. Why is registration needed for each case?

The statement can solve some complication but should be put in context of use cases. 

Phil

On 2013-08-18, at 15:01, Hannes Tschofenig <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> -----BEGIN PGP SIGNATURE-----
> iQEcBAEBCgAGBQJSEUQfAAoJEGhJURNOOiAt8wkIAI3xgdsWuOB36KLiMLRUG+Zb
> RvYqV+rOH80m7YVJcdOLjQJcpPqOIBdzq/yuNiAaF1uFJCqBn97ZQ/NLXLNGcg8x
> wI/Laz7kP2U4B2trBTMtAf2wsY9uYw4Eh+eOEDKGF6cmkEzrzrlw4q/Sfu6vy181
> VI+kqwzZ+iYX4iL3NYPlkg3rwF4OZ1v3T08Erg2SPrbmNd1TRfJJU8HrYFEJQo1q
> p0RiLjcFFDCEZs0gDr9zliCXllV7J9h2ttqLq8+xwPATDuO6buQdFS9vZQ8t1u36
> a0FIuy3NM8PQbblC3B5WumUjW4kntLV09ytYV8h6S8C/dgFwMqzAwEAeNx1exyE=
> =3qNI
> -----END PGP SIGNATURE-----
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Mon, 19 Aug 2013 10:26:51 -0400

I agree that dynamic registration isn't needed to solve *all* of the 
different use cases. It solves its set of specific problems (and does so 
well, if you ask me), but there are and will always be things that it 
won't work for, and that's fine. That's why I've suggested under a 
separate thread that the other drafts go forward separately and that 
DynReg not be hung up on them. We're fundamentally solving different use 
cases, and there is no magic solution that will solve all the problems 
at once.

  -- Justin

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 19 Aug 2013 15:15:53 +0000

There are proposals out there that are trying to solve the same problem, but in different ways, so I would not say that they are trying to solve different use cases. I do think that we need to make sure that whatever proposal we select it needs to have a wide range of use cases it solves, not just a single use case as the more solutions this group produces the more confused folks will be

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Monday, August 19, 2013 7:27 AM
To: Phil Hunt
Cc: oauth mailing list
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

I agree that dynamic registration isn't needed to solve *all* of the different use cases. It solves its set of specific problems (and does so well, if you ask me), but there are and will always be things that it won't work for, and that's fine. That's why I've suggested under a separate thread that the other drafts go forward separately and that DynReg not be hung up on them. We're fundamentally solving different use cases, and there is no magic solution that will solve all the problems at once.

  -- Justin

On 08/18/2013 08:15 PM, Phil Hunt wrote:
>> * SCIM vs. current dynamic client registration approach for 
>> interacting with the client configuration endpoint
>>

---

From: Justin Richer <[email-masked]>
Date: Mon, 19 Aug 2013 11:18:27 -0400

Tony, I completely disagree. The proposals that I've seen have different 
means and different end states, and they make different assumptions 
about the relationship between entities and the capabilities of all 
players.

  -- Justin

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 19 Aug 2013 15:28:00 +0000

What you say does not mean that they are trying to solve different use cases, they have gone about solving the different use cases in different ways and have different relationships with different actors, etc. within the use cases.

-----Original Message-----
From: Justin Richer [mailto:[email-masked]] 
Sent: Monday, August 19, 2013 8:18 AM
To: Anthony Nadalin
Cc: Phil Hunt; oauth mailing list
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT

Tony, I completely disagree. The proposals that I've seen have different means and different end states, and they make different assumptions about the relationship between entities and the capabilities of all players.

  -- Justin

On 08/19/2013 11:15 AM, Anthony Nadalin wrote:
> There are proposals out there that are trying to solve the same 
> problem, but in different ways, so I would not say that they are 
> trying to solve different use cases. I do think that we need to make 
> sure that whatever proposal we select it needs to have a wide range of 
> use cases it solves, not just a single use case as the more solutions 
> this group produces the more confused folks will be
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 19 Aug 2013 08:33:30 -0700

I do not recall agreement in charter discussions to solving a specific case. 

I recall more than one in the re-chartering discussion said dyn reg needed major changes to solve their use cases. 

Phil

---

From: Justin Richer <[email-masked]>
Date: Mon, 19 Aug 2013 11:31:59 -0400

All of this is a good argument to do both, which is what I've been 
saying all along.

  -- Justin

---

From: Eve Maler <[email-masked]>
Date: Mon, 19 Aug 2013 16:33:13 -0700

Hi folks-- Just a reminder that the first draft the UMA group submitted on May 1, 2011 contained extensive requirements and use cases related to UMA's various needs for dynamic client registration:

http://tools.ietf.org/html/draft-hardjono-oauth-dynreg-00

When there was interest to pick up this draft as a WG work item, it was recommended that we excise this content so that the doc wouldn't be so specific to our particular usage of OAuth.

I point this out just to show that the need for dynamic client registration isn't limited to OpenID Connect, and that some specific use cases have already been floated here.

FWIW,

	Eve

On 19 Aug 2013, at 8:31 AM, Justin Richer <[email-masked]> wrote:

> All of this is a good argument to do both, which is what I've been saying all along.
> 
> -- Justin
> 

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: Phil Hunt <[email-masked]>
Date: Mon, 19 Aug 2013 16:51:19 -0700

The reason I want to go over the cases is some seem to think uma and oidc are all the use cases. As Justin points out they are very specific. 

It doesn't seem like the dyn reg proposal is general enough to meet the wg charter's intent. At least from what i recall of the discussion. 

While i think some concepts in scim reg move things forward, i dont think it should move forward either. There should be one approach. Or failing that a strong taxonomy that makes it clear why multiple approaches are needed. Lack of consensus is not such a reason IMHO. 

I want to ask fundamental questions like what problem is being solved and what needs to be done for each client type. 

The assumption that client id must be issued by the sp seems wrong to me in many cases-- including oidc. 6749 does not make this restriction at all. 

Given this, a statement approach may be sufficient for many clients. No need for long term credential mgmt or records. 

Phil

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 20 Aug 2013 07:34:21 +0200

Hi Phil,

>The assumption that client id must be issued by the sp seems wrong to
>me in many cases-- including oidc. 6749 does not make this restriction
>at all. 

What do you mean? Grant type code requires a client_id in order to identify the client at the AS's authz endpoint. Based on this data, the AS chooses the authz policy and validates the redirect_uri.

>
>Given this, a statement approach may be sufficient for many clients. No
>need for long term credential mgmt or records. 

Perhaps for clients using the token endpoint only.

regards,
Torsten.

>> Hi folks-- Just a reminder that the first draft the UMA group
>submitted on May 1, 2011 contained extensive requirements and use cases
>related to UMA's various needs for dynamic client registration:
>> 
>> When there was interest to pick up this draft as a WG work item, it
>was recommended that we excise this content so that the doc wouldn't be
>so specific to our particular usage of OAuth.
>> 
>> I point this out just to show that the need for dynamic client
>registration isn't limited to OpenID Connect, and that some specific
>use cases have already been floated here.
>> 
>> FWIW,
>> 
>>    Eve
>> 
>>>> I recall more than one in the re-chartering discussion said dyn reg
>needed major changes to solve their use cases.
>>>> 
>>>> Phil
>>>> 
>>>>> Tony, I completely disagree. The proposals that I've seen have
>different means and different end states, and they make different
>assumptions about the relationship between entities and the
>capabilities of all players.
>>>>> 
>>>>> -- Justin
>>>>> 
>problem, but in different ways, so I would not say that they are trying
>to solve different use cases. I do think that we need to make sure that
>whatever proposal we select it needs to have a wide range of use cases
>it solves, not just a single use case as the more solutions this group
>produces the more confused folks will be
>>>>>> 
>>>>>> I agree that dynamic registration isn't needed to solve *all* of
>the different use cases. It solves its set of specific problems (and
>does so well, if you ask me), but there are and will always be things
>that it won't work for, and that's fine. That's why I've suggested
>under a separate thread that the other drafts go forward separately and
>that DynReg not be hung up on them. We're fundamentally solving
>different use cases, and there is no magic solution that will solve all
>the problems at once.
>>>>>> 
>>>>>>  -- Justin
>>>>>> 
>>>>>>> Then a discussion on any client_id assumptions and actual
>requirements for each client case. Why is registration needed for each
>case?
>>>>>>> 
>>>>>>>> Based on your feedback via the poll let us start with August
>22nd with the first conference call. I will distribute the conference
>call details on Tuesday.
>>>>>>>> 
>>>>>>>> Let us talk about the agenda. There were several items brought
>up in
>>>>>>>> discussions, namely
>>>>>>>> 
>>>>>>>> We briefly discussed this topic at the IETF OAuth session but
>we may need more time to understand the implications for the current
>dynamic client registration document:
>>>>>>>>
>>>>>>>> In the past we said that it would be fine to have a profile
>defined in SCIM to provide the dynamic client registration for those
>who implement SCIM and want to manage clients also using SCIM. It
>might, however, be useful to compare the two approaches in detail to
>see what the differences are.
>>>>>>>> 
>>>>>>>> Justin added some "life cycle" description to the document to
>motivate some of the design decisions. Maybe we need to discuss those
>in more detail and add further text.
>>>>>>>> - - From the discussions on the list it was not clear whether
>this is actually accomplishable with the current version of OAuth. We
>could explore this new requirement and try to get a better
>understanding how much this relates to dynamic client registration and
>to what extend it requires changes to the core spec.
>>>>>>>> 
>>>>>>>>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 19 Aug 2013 22:53:46 -0700

See below

Phil

> What do you mean? Grant type code requires a client_id in order to identify the client at the AS's authz endpoint. Based on this data, the AS chooses the authz policy and validates the redirect_uri.

[ph] yes. But i am referring to the fact that the client does not have to obtain it from the as. It merely has to present one that is accepted. 

Iow a federated assertion might solve the issue. 
> Perhaps for clients using the token endpoint only.

[Ph] Actually I was also thinking of javascript clients.

---

From: Phil Hunt <[email-masked]>
Date: Mon, 19 Aug 2013 23:12:26 -0700

Sorry i see my message still isn't that clear.  I am saying there is no requirement that a client directly obtain a client_id from the as service provider. It is merely an assumption that has been made by dyn reg based on typical use patterns to date. 

It could be reasonable for a client to generate it's own guid or more likely, use an assertion signed by a party the service provider trusts. 

Phil

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 20 Aug 2013 11:34:15 +0200

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 have any information regarding the client id in the code flow at authz endpoint.

This needs to be taken into account.

regards,
Torsten.

---

From: Phil Hunt <[email-masked]>
Date: Tue, 20 Aug 2013 07:42:24 -0700

+1

The chosen solution should account for this.  

Phil

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 20 Aug 2013 14:50:07 +0000

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 the discussion about these specific design choices for the dynamic client registration protocol since the UMA use cases are more high-level. 

What we would, for example, need (at least I think so) are scenarios at the level of "client generates a client id (instead of AS). What is the motivation? What are the implications for the protocol interaction and for security?"

If someone from the UMA community could provide me with use cases that are focused to help me answer questions like the one above that would be helpful. 

Ciao
Hannes

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Eve Maler
> Sent: Tuesday, August 20, 2013 1:33 AM
> To: Justin Richer
> Cc: oauth mailing list
> Hi folks-- Just a reminder that the first draft the UMA group submitted
> on May 1, 2011 contained extensive requirements and use cases related
> to UMA's various needs for dynamic client registration:
> 
> When there was interest to pick up this draft as a WG work item, it was
> recommended that we excise this content so that the doc wouldn't be so
> specific to our particular usage of OAuth.
> 
> >>>>>> We briefly discussed this topic at the IETF OAuth session but we
> may need more time to understand the implications for the current
> who implement SCIM and want to manage clients also using SCIM. It might,
> however, be useful to compare the two approaches in detail to see what
> the differences are.
> >>>>>>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 20 Aug 2013 14:51:49 +0000

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 case?

I guess you are bringing the use case to the table where there is no client id needed (?) or where the client id is provided by yet another party (other than the one running the AS). 

Ciao
Hannes

> > Based on your feedback via the poll let us start with August 22nd
> with the first conference call. I will distribute the conference call
> details on Tuesday.
> >
> > We briefly discussed this topic at the IETF OAuth session but we may
> need more time to understand the implications for the current dynamic
> client registration document:
> > In the past we said that it would be fine to have a profile defined
> in SCIM to provide the dynamic client registration for those who
> implement SCIM and want to manage clients also using SCIM. It might,
> > - - From the discussions on the list it was not clear whether this is
> actually accomplishable with the current version of OAuth. We could
> explore this new requirement and try to get a better understanding how
> much this relates to dynamic client registration and to what extend it
> requires changes to the core spec.
> >
> >

---

From: Phil Hunt <[email-masked]>
Date: Tue, 20 Aug 2013 08:12:38 -0700

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 important factors is first how the server recognizes the client that is registering. It needs to do this to set or associate policy. 

What does a service provider gain if it has no information about clients? The downside of issuing random client_ids is little or no policy based access control and resource depletion. 

So we have to ask ourselves in each case why register? What is achieved for each side? Client id is a major factor but it is not THE factor. 

Phil

---

From: Josh Mandel <[email-masked]>
Date: Tue, 20 Aug 2013 08:30:16 -0700

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 `registration_jwt` (issued by a third party
and presented by the client to the registration endpoint at registration
time)

We used this classification with the current dyn-reg draft, in order to
give implementers a concrete idea about how policy might vary according to
client type. Part of why this works nicely for BB+ is that we actually get
to control (well, specify!) policy within the BB+ network.

  -Josh

On Tue, Aug 20, 2013 at 8:12 AM, Phil Hunt <[email-masked]> wrote:

> As Torsten mentions one of the most important factors is first how the
> server recognizes the client that is registering. It needs to do this to
> set or associate policy.
>
> What does a service provider gain if it has no information about clients?
> The downside of issuing random client_ids is little or no policy based
> access control and resource depletion.
>
> So we have to ask ourselves in each case why register? What is achieved
> for each side? Client id is a major factor but it is not THE factor.
>
> Phil
>
> > I guess you are bringing the use case to the table where there is no
> client id needed (?) or where the client id is provided by yet another
> party (other than the one running the AS).
> >
> >>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 20 Aug 2013 09:04:51 -0700

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
[email-masked]

On 2013-08-20, at 8:30 AM, Josh Mandel <[email-masked]> wrote:

> The group may be interested in bits of the following classification that we put together for BlueButton+:
> 2.  whether they can protect a `registration_jwt` (issued by a third party and presented by the client to the registration endpoint at registration time)
> 
> We used this classification with the current dyn-reg draft, in order to give implementers a concrete idea about how policy might vary according to client type. Part of why this works nicely for BB+ is that we actually get to control (well, specify!) policy within the BB+ network.
> 
>   -Josh
> 
>

---

From: George Fletcher <[email-masked]>
Date: Tue, 20 Aug 2013 12:22:44 -0400

From a use case perspective... do we need to take this back to the 
level of why do we need to do registration in the first place?

Current assumed reasons for registration:
1. callback URL specification as some Authorization Services require 
pre-registration
2. client meta-data data (useful for UI presentation to the user during 
authorization flows)
3. client identification often necessary for managing policy decisions
4. others?

[Personally, the concept of an application being able to access a 
protected resource without registering at all is orthogonal to this 
issue of dynamic registration and should be solved separately.]

Different cases for authorization policy
1. User-centric where the user explicitly grants a given app some set of 
limited authorizations
2. AS controlled authorization where the AS grants a set of limited 
authorizations based on the identification of the client outside of the 
user's control
3. Enterprise/policy based authorizations. These may include the user 
identity but are not dependent on the user's consent.
4. Others?

 From my perspective... here are the use cases we want to support

1. Client application can obtain an instance specific client 
identification and secret. This is for deployment of mobile apps.
2. Client applications can easily register with multiple Authorization 
Servers. For consumer based applications this will be more and more 
critical as application level protocols standardize on OAuth2 for API 
security.
3. Consumer friendly experience... meaning that the consumer can easily 
understand what client is requesting which scopes so that the user can 
make an informed decision.
4. Server side revocation of both client instances and classes of clients

One of my concerns with moving solely to the "assertion/statement" model 
is that it requires the client to send a lot of state with every request 
which increases the number of bytes on the wire. Given that all of this 
data is still just bearer data (must be protected by the client)... 
doing an upfront registration with the larger set of data and then using 
a reference (client_id) to that data makes a lot of sense to me.

Sorry for the mishmash of thoughts:)

George

-- 
George Fletcher <http://connect.me/gffletch>

---

From: Josh Mandel <[email-masked]>
Date: Tue, 20 Aug 2013 09:36:26 -0700

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.2<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-14#appendix-B.2>of
dyn-reg-14).

Does this make sense?  (Happy to provide more detail if it would help.)

  -J

---

From: Justin Richer <[email-masked]>
Date: Tue, 20 Aug 2013 12:32:35 -0400

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 talked about at IIW this year (and what I had suggested to 
Morteza for his use case), and it's all detailed on the same page that 
Josh linked:

http://blue-button.github.io/blue-button-plus-pull/#registration-trusted

When designing the BB+ registration system (which directly influenced 
the OAuth DynReg current draft, as I've said many times), we were 
careful about where we drew the lines dividing the two systems. You'll 
note that the BB+ "Open Registration" is exactly the OAuth DynReg 
registration, and that the "Trusted Registration" builds directly on top 
of that, but requires an assertion format (JWT), a discovery system, a 
manual pre-registration step, and a policy that vets a network of 
Registries to manage everything. We decided fairly early on that there 
was too much baggage to bring the full BB+ Trusted Registration over to 
a general use case, but I've continually pointed out its existence and 
asked you (Phil) to read it when you've brought up the software assertions.

  -- Justin

On 08/20/2013 12:04 PM, Phil Hunt wrote:
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>
>
> On 2013-08-20, at 8:30 AM, Josh Mandel <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> 2.  whether they can protect a `registration_jwt` (issued by a third 
>> party and presented by the client to the registration endpoint at 
>> registration time)
>>
>> We used this classification with the current dyn-reg draft, in order 
>> to give implementers a concrete idea about how policy might vary 
>> according to client type. Part of why this works nicely for BB+ is 
>> that we actually get to control (well, specify!) policy within the 
>> BB+ network.
>>
>> -Josh
>>
>>
>> On Tue, Aug 20, 2013 at 8:12 AM, Phil Hunt <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     As Torsten mentions one of the most important factors is first
>>     how the server recognizes the client that is registering. It
>>     needs to do this to set or associate policy.
>>
>>     What does a service provider gain if it has no information about
>>     clients? The downside of issuing random client_ids is little or
>>     no policy based access control and resource depletion.
>>
>>     So we have to ask ourselves in each case why register? What is
>>     achieved for each side? Client id is a major factor but it is not
>>     THE factor.
>>
>>     Phil
>>
>>     On 2013-08-20, at 7:51, ", Hannes (NSN - FI/Espoo)"
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     > Hi Phil,
>>     >
>>     >
>>     requirements
>>     > I guess you are bringing the use case to the table where there
>>     is no client id needed (?) or where the client id is provided by
>>     yet another party (other than the one running the AS).
>>     >
>>     >>
>>     >> The statement can solve some complication but should be put in
>>     context
>>     >> of use cases.
>>     >
>>     > Ciao
>>     > Hannes
>>     >
>>     >> Phil
>>     >>
>>     >> On 2013-08-18, at 15:01, Hannes Tschofenig
>>     <[email-masked] <mailto:[email-masked]>>
>>     >> wrote:
>>     >>
>>     >>> Let us talk about the agenda. There were several items
>>     brought up in
>>     >> discussions, namely
>>     >>>
>>     we may
>>     defined
>>     >>> Additional text could come from the NIST Blue Button / Green
>>     Button
>>     >> usage.
>>     >>>
>>     this is
>>     >>> Comment: GPGTools - http://gpgtools.org <http://gpgtools.org/>
>>     >>>
>>     >>> Comment: GPGTools - http://gpgtools.org <http://gpgtools.org/>
>>     >>>
>>     >>> [email-masked] <mailto:[email-masked]>
>>     >> [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 20 Aug 2013 19:40:31 +0000

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 part of it.

It would be interesting to hear what specifically BlueButton (in terms of use cases) contributes.

Ciao
Hannes

From: ext Josh Mandel [mailto:[email-masked]]
Sent: Tuesday, August 20, 2013 6:36 PM
To: Phil Hunt
Cc: Tschofenig, Hannes (NSN - FI/Espoo); oauth mailing list
Subject: 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.2<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-14#appendix-B.2> of dyn-reg-14).

  -J

On Tue, Aug 20, 2013 at 9:04 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
Josh,

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On 2013-08-20, at 8:30 AM, Josh Mandel <[email-masked]<mailto:[email-masked]>> wrote:

  -Josh

On Tue, Aug 20, 2013 at 8:12 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
By taxonomy i mean the distinct types of clients and associations.

Eg
- javascript
- native app
- web app

There are probably more.

Phil

On 2013-08-20, at 7:51, ", Hannes (NSN - FI/Espoo)" <[email-masked]<mailto:[email-masked]>> wrote:

>> On 2013-08-18, at 15:01, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
>> wrote:
>>
>>> Comment: GPGTools - http://gpgtools.org<http://gpgtools.org/>
>>>
>>> Comment: GPGTools - http://gpgtools.org<http://gpgtools.org/>
>>>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth