Subject: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 28 Aug 2013 12:43:44 +0000

Here are the conference bridge / Webex details for the call today. 
We are going to complete the use case discussions from last time (Phil wasn't able to walk through all slides). Justin was also able to work out a strawman proposal based on the discussions last week and we will have a look at it to see whether this is a suitable compromise. Here is Justin's mail, in case you have missed it: http://www.ietf.org/mail-archive/web/oauth/current/msg12036.html 

Phil, please feel free to make adjustments to your slides given the Justin's recent proposal.

Topic: OAuth Dynamic Client Registration 
Date: Wednesday, August 28, 2013 
Time: 2:00 pm, Pacific Daylight Time (San Francisco, GMT-07:00) 
Meeting Number: 703 230 586 
Meeting Password: oauth 

------------------------------------------------------- 
To join the online meeting 
------------------------------------------------------- 
1. Go to https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&PW=NNTI1ZWQzMDJk&RT=MiM0  
2. Enter your name and email address. 
3. Enter the meeting password: oauth 
4. Click "Join Now". 

To view in other time zones or languages, please click the link: 
https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&PW=NNTI1ZWQzMDJk&ORT=MiM0   

To add this meeting to your calendar program (for example Microsoft Outlook), click this link: 
https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=C6-AjLGvhdYjmpVdx75M6UsAwrNLMsequ5n95Gyv1R8=&RT=MiM0

------------------------------------------------------- 
To join the teleconference only 
------------------------------------------------------- 
Global dial-in Numbers: http://www.nokiasiemensnetworks.com/nvc  
Conference Code: 944 910 5485

---

From: Phil Hunt <[email-masked]>
Date: Wed, 28 Aug 2013 08:04:26 -0700

I have a conflict I cannot get out of for 2pacific. 

I think a certificate based approach is going to simplify exchanges in all cases. I encourage the group to explore the concept on the call. 

I am not sure breaking dyn reg up helps. It creates yet another option. I would like to explore how federation concept in software statements can help with facilitating association and making many reg stateless. 

Phil

On 2013-08-28, at 5:43, "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Wed, 28 Aug 2013 08:17:54 -0700

Sorry. I meant also to say i think there are 2 registration steps. 

1. Software registration/approval. This often happens out of band. But in this step policy is defined that approves software for use. Many of the reg params are known here. 

Federation techniques come into play as trust approvals can be based on developer, product or even publisher. 

2. Each instance associates in a stateless way. Only clients that need credential rotation need more. 

Phil

---

From: Justin Richer <[email-masked]>
Date: Wed, 28 Aug 2013 11:41:40 -0400

Except for the cases where you want step 1 to happen in band. To me, 
that is a vitally and fundamentally important use case that we can't 
disregard, and we must have a solution that can accommodate that. The 
notions of "publisher" and "product" fade very quickly once you get 
outside of the software vendor world.

This is, of course, not to stand in the way of other solutions or 
approaches (such as something assertion based like you're after). It's 
not a one-or-the-other proposition, especially when there are mutually 
exclusive aspects of each.

Therefore I once again call for the WG to finish the current dynamic 
registration spec *AND* pursue the assertion based process that Phil's 
talking about. They're not mutually exclusive, let's please stop talking 
about them like they are.

  -- Justin

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 28 Aug 2013 15:49:40 +0000

>Therefore I once again call for the WG to finish the current dynamic registration spec *AND* pursue the assertion based process that Phil's talking about. They're not mutually exclusive, let's please stop talking 

I see no reason to continue to push finish the current specification when there are so many discussions/issues going on as discussions will only lead to better specifications that folks can actually implement and use.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Wednesday, August 28, 2013 8:42 AM
To: Phil Hunt
Cc: oauth mailing list
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details

Except for the cases where you want step 1 to happen in band. To me, that is a vitally and fundamentally important use case that we can't disregard, and we must have a solution that can accommodate that. The notions of "publisher" and "product" fade very quickly once you get outside of the software vendor world.

This is, of course, not to stand in the way of other solutions or approaches (such as something assertion based like you're after). It's not a one-or-the-other proposition, especially when there are mutually exclusive aspects of each.

Therefore I once again call for the WG to finish the current dynamic registration spec *AND* pursue the assertion based process that Phil's talking about. They're not mutually exclusive, let's please stop talking about them like they are.

  -- Justin

On 08/28/2013 11:17 AM, Phil Hunt wrote:
>>> We are going to complete the use case discussions from last time 
>>> (Phil wasn't able to walk through all slides). Justin was also able 
>>> to work out a strawman proposal based on the discussions last week 
>>> and we will have a look at it to see whether this is a suitable 
>>> compromise. Here is Justin's mail, in case you have missed it: 
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg12036.html
>>>
>>> Meeting Number: 703 230 586 Meeting Password: oauth
>>>
>>> 1. Go to 
>>> https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&PW=NNTI1ZWQzMDJk&
>>> RT=MiM0 2. Enter your name and email address.
>>> 3. Enter the meeting password: oauth 4. Click "Join Now".
>>>
>>> https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&ICS=MI&LD=1&RD=2&
>>> ST=1&SHA2=C6-AjLGvhdYjmpVdx75M6UsAwrNLMsequ5n95Gyv1R8=&RT=MiM0
>>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 28 Aug 2013 11:51:12 -0400

Except that folks are already actually implementing and using the spec, 
and that all of the discussions around different specs are pretty 
clearly pointing to different use cases and assumptions about the state 
of the world.

Your arguments are invalid.

  -- Justin

On 08/28/2013 11:49 AM, Anthony Nadalin wrote:
>>>> ORT=MiM0

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 28 Aug 2013 16:01:12 +0000

So I guess we should have different specifications for different use cases to solve same requirements, I guess we should have done that we OAuth and not worked out common flows, patterns, parameters, etc. I have only seen 2-3 respond to the implementation status, once again people should post if they:

1. have implemented this as is
2. plan on implementing as is
3. what use case they are solving
4. what modifications needed on top of this specification to actually solve use case

-----Original Message-----
From: Justin Richer [mailto:[email-masked]] 
Sent: Wednesday, August 28, 2013 8:51 AM
To: Anthony Nadalin
Cc: Phil Hunt; oauth mailing list
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details

Except that folks are already actually implementing and using the spec, and that all of the discussions around different specs are pretty clearly pointing to different use cases and assumptions about the state of the world.

  -- Justin

On 08/28/2013 11:49 AM, Anthony Nadalin wrote:
>> registration spec *AND* pursue the assertion based process that 
>> Phil's talking about. They're not mutually exclusive, let's please 
>> stop talking
> Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: 
> Wed 28 Aug, 2pm PDT: Conference Bridge Details
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 28 Aug 2013 09:02:24 -0700

Please define the all in one case. I think this is the edge case and is in fact rare. 

I agree, in many cases step 1 can be made by simply approving a class of software. But then step 2 is simplified. 

Dyn reg assumes every registration of an instance is unique which too me is a very extreme position. 

Phil

---

From: Justin Richer <[email-masked]>
Date: Wed, 28 Aug 2013 12:06:48 -0400

I think it makes perfect sense to have different spects for different 
use cases to solve different requirements (and the requirements *are* 
different -- you keep bringing up fully stateless registration and 
that's just not a requirement for many people). The different specs can 
(and should) use common parameters and data models where it makes sense, 
and differ where it makes sense. You know, just like we did with the 
OAuth flows. There's a reason that the Client Credentials flow doesn't 
use the authorization endpoint, but the Code flow does. And there's also 
a reason why the "grant_type" parameter is an explicit extension point 
in OAuth.

The as-of-yet-completely-unspecified-and-unimplemented software 
assertions based "spec" can re-use the client model from the current 
dyn-reg, if it wants to and it makes sense to. It can use the same 
parameter names. Nobody's saying not to do that, Tony. But in addition 
to the responders who have implemented Dyn-Reg as it is, I'd like to 
hear from people who have implemented the stateless proposal as well. 
Anyone?

  -- Justin

---

From: Justin Richer <[email-masked]>
Date: Wed, 28 Aug 2013 12:08:38 -0400

I set up an auth server to protect my API, my users download a piece of 
software that speaks the API to access their data. Where is my server 
supposed to get the list of "approved" software classes from? Are you 
assuming a central registry per API? Or is it going to be 
provider-specific? If the latter, why wouldn't you just do manual 
registration and not use dynamic registration at all? After all, manual 
registration will always still be a valid option.

  -- Justin

---

From: George Fletcher <[email-masked]>
Date: Wed, 28 Aug 2013 12:20:35 -0400

On 8/28/13 12:02 PM, Phil Hunt wrote:
> Dyn reg assumes every registration of an instance is unique which too me is a very extreme
If you have a mobile app that needs to do the code flow... which 
requires a client_secret in order to retrieve the access token and 
refresh token, how does the app do this without per app instance 
registration?

I'd argue that almost all user facing mobile apps will want the above 
flow and that's not a small, rare edge case.

Thanks,
George
> position.

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

---

From: Phil Hunt <[email-masked]>
Date: Wed, 28 Aug 2013 09:20:56 -0700

This is the key problem with dyn reg. 

You have to recognize software as distinct entities shared by clients as instances. Statements can be by a developer, an organization or an api owner that approves clients in the same way google or facebook does today. 

The approval happens once per client software or can even happen once per publisher or developer depending on trust. 

Dyn reg doesn't work in practice because each registration has to be approved individually yet the protocol doesn't support approvals. It must be immediate. 

This is why the question of who has used this in production matters. Implementation of dyn reg is easy. Operating it looks workable only in small installations. 

Phil

On 2013-08-28, at 9:08, Justin Richer <[email-masked]> wrote:

> I set up an auth server to protect my API, my users download a piece of software that speaks the API to access their data. Where is my server supposed to get the list of "approved" software classes from? Are you assuming a central registry per API? Or is it going to be provider-specific? If the latter, why wouldn't you just do manual registration and not use dynamic registration at all? After all, manual registration will always still be a valid option.
> 
> -- Justin
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 28 Aug 2013 09:23:49 -0700

George

That case can be solved with a simple assertion swap. We just have to profile it. 

Phil

On 2013-08-28, at 9:20, George Fletcher <[email-masked]> wrote:

> If you have a mobile app that needs to do the code flow... which requires a client_secret in order to retrieve the access token and refresh token, how does the app do this without per app instance registration? 
> 
> I'd argue that almost all user facing mobile apps will want the above flow and that's not a small, rare edge case.
> 
> Thanks,
> George
>> position. 
>> 
>> Phil
>> 
> <XeC>

---

From: George Fletcher <[email-masked]>
Date: Wed, 28 Aug 2013 12:27:49 -0400

Maybe I'm missing something...
> The approval happens once per client software or can even happen once per publisher or developer depending on trust.
Isn't this what the Initial Access Token is all about in the current 
spec? An "assertion" can be provided to the software developer for them 
to use with the registration endpoints.
> Dyn reg doesn't work in practice because each registration has to be approved individually yet the protocol doesn't support approvals. It must be immediate.
I'm confused... what do you mean by approvals? If the initial "software 
statement" (i.e. token/assertion) identifies the developer or class of 
client or whatever, the AS can apply the necessary policy to determine 
if it wants to allow the instance to register. The AS doesn't have to 
make decisions based on the data provided by the instance, it could make 
them based on the data provided in the Initial Access Token. The AS 
could easily provide a client_id to the instance that is really a 
structured token such that the AS implementation is stateless.
> This is why the question of who has used this in production matters. Implementation of dyn reg is easy. Operating it looks workable only in small installations.
What policy an AS applies to a client_id is out of scope of OAuth and 
always has been. So whats the complication in this case? I can see a 
number of easy ways to solve the approval/authorization from an AS 
implementation perspective.

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 28 Aug 2013 16:28:19 +0000

I do think that this is the rare-edge use case, we would not want require client-secret, we already have that mess today with OAuth and trying not to continue the proliferation, we solve this today with our STS and assertion swaps/transformations, it scales, performs and we don't have the management debacle this specification creates

From: [email-masked] [mailto:[email-masked]] On Behalf Of George Fletcher
Sent: Wednesday, August 28, 2013 9:21 AM
To: Phil Hunt
Cc: oauth mailing list
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details

Thanks,
George

position.

Phil

On 2013-08-28, at 8:41, Justin Richer <[email-masked]><mailto:[email-masked]> wrote:

-- Justin

Sorry. I meant also to say i think there are 2 registration steps

Phil

On 2013-08-28, at 8:04, Phil Hunt <[email-masked]><mailto:[email-masked]> wrote:

Phil

On 2013-08-28, at 5:43, "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]><mailto:[email-masked]> wrote:

Meeting Password: oauth

4. Click "Join Now".

OAuth mailing list

[email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: George Fletcher <[email-masked]>
Date: Wed, 28 Aug 2013 12:29:30 -0400

I can't say I understand what you mean by a simple assertion swap... but 
if you are wanting to use a client_assertion flow instead of the code 
flow then that's something completely different. If you are saying that 
you want the client_id to represent an "instance" in a stateless way 
using an "assertion" then that's already possible today.

George

On 8/28/13 12:23 PM, Phil Hunt wrote:
> On 2013-08-28, at 9:20, George Fletcher <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>
>>> On 2013-08-28, at 8:41, Justin Richer<[email-masked]>  wrote:
>>>
>>>>> On 2013-08-28, at 8:04, Phil Hunt<[email-masked]>  wrote:
>>>>>
>>>>>> On 2013-08-28, at 5:43, "Tschofenig, Hannes (NSN - FI/Espoo)"<[email-masked]>  wrote:
>>>>>>
>>>>>>> We are going to complete the use case discussions from last time (Phil wasn't able to walk through all slides). Justin was also able to work out a strawman proposal based on the discussions last week and we will have a look at it to see whether this is a suitable compromise. Here is Justin's mail, in case you have missed it:http://www.ietf.org/mail-archive/web/oauth/current/msg12036.html
>>>>>>>
>>>>>>> 1. Go tohttps://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&PW=NNTI1ZWQzMDJk&RT=MiM0
>>>>>>> Global dial-in Numbers:http://www.nokiasiemensnetworks.com/nvc
>> <XeC> <http://connect.me/gffletch>

---

From: George Fletcher <[email-masked]>
Date: Wed, 28 Aug 2013 12:33:27 -0400

So I understand that you'd rather that OAuth doesn't require a 
client_secret and that's fine. However, I don't think we should impose 
that thinking on the rest of the world who have already implemented it 
and have it working and scaling without issues. If the core of this 
discussion is around replacing client_id and client_secret with a 
client_assertion then lets have that discussion separately and not bury 
it in the dynamic registration discussion.

Could you not profile OAuth2 to support a flow that allows for retrieval 
of access and refresh tokens using code + client_assertion? Doesn't seem 
like that hard a profile and then the rest of this could fall out pretty 
easily.

Thanks,
George

On 8/28/13 12:28 PM, Anthony Nadalin wrote:
>
> I do think that this is the rare-edge use case, we would not want 
> require client-secret, we already have that mess today with OAuth and 
> trying not to continue the proliferation, we solve this today with our 
> STS and assertion swaps/transformations, it scales, performs and we 
> don't have the management debacle this specification creates
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *George Fletcher
> *Sent:* Wednesday, August 28, 2013 9:21 AM
> *To:* Phil Hunt
> *Cc:* oauth mailing list
> *Subject:* Re: [OAUTH-WG] Dynamic Client Registration Conference Call: 
>     On 2013-08-28, at 8:41, Justin Richer<[email-masked]>  <mailto:[email-masked]>  wrote:
>
>       
>
>             On 2013-08-28, at 8:04, Phil Hunt<[email-masked]>  <mailto:[email-masked]>  wrote:
>
>               
>
>                 On 2013-08-28, at 5:43, "Tschofenig, Hannes (NSN - FI/Espoo)"<[email-masked]>  <mailto:[email-masked]>  wrote:
>
>                   
>
>                     [email-masked]  <mailto:[email-masked]>
>
>                 [email-masked]  <mailto:[email-masked]>
>
>             [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 28 Aug 2013 17:34:10 +0100

> This is why the question of who has used this in production matters. Implementation of dyn reg is easy. Operating it looks workable only in small installations.

What concerns me is that while it is obviously important that large 
installations should be supported, there does not seem to be much 
motivation to worry about the small installations. But the thing is, 
without the small installations, the possibility is OAuth apps will be 
developed by developers working for large OAuth providers only.

I'm sorry, I realize it is not much in scope of this discussion, my 
comment, but it worries me how strong a push is to get the JWT or SAML 
assertions becoming the main 'artifacts' of OAuth.

Cheers, Sergey

---

From: Phil Hunt <[email-masked]>
Date: Wed, 28 Aug 2013 09:35:39 -0700

George,

It would be reasonable for a client to submit an assertion, and obtain its own client assertion in return.  This is very close to what is happening per 2.1, 2.2 of http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-06

In this case, the Software Statement is an authorization that is exchanged for a client assertion in return. Then the clients authenticate per section 2.2 of the JWT spec.

Regarding initial_access_token.  This does have some of the characteristics I am speaking of. But it is unspecified and the assumption is that it is issued by the local domain.  This doesn't work in the UMA case because that's more like a federated model. Thus the specified software statement works because the AS can approve the client software based on name, and/or developer, and/or publisher -- whatever trust requires.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-08-28, at 9:29 AM, George Fletcher <[email-masked]> wrote:

> I can't say I understand what you mean by a simple assertion swap... but if you are wanting to use a client_assertion flow instead of the code flow then that's something completely different. If you are saying that you want the client_id to represent an "instance" in a stateless way using an "assertion" then that's already possible today.
> 
> George
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 28 Aug 2013 17:38:07 +0100

> like that hard a profile and then the rest of this could fall out pretty
That is already supported AFAIK, something like

grant_type=authorization_code
&code=12345678
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Asaml2-bearer
&client_assertion=Base64UrlEncoded-SAML2-Bearer-Assertion

probably the same works with JWT

Sergey

>> don’t have the management debacle this specification creates
>>

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

---

From: Justin Richer <[email-masked]>
Date: Wed, 28 Aug 2013 12:39:27 -0400

The initial_access_token doesn't assume that it's from the local domain. 
It merely assumes that the authorization server accepts the token, which 
would be true in the UMA case due to the federation. It could also be 
the exact same kinds of mechanisms that the software statement would use 
to achieve federation.

I still don't see how an auth server is going to know about a client's 
configuration state with the assertion swap method, since there's no 
defined mechanism for sending a JWT assertion to the authorization 
endpoint.

  -- Justin

On 08/28/2013 12:35 PM, Phil Hunt wrote:
> George,
>
> It would be reasonable for a client to submit an assertion, and obtain 
> its own client assertion in return.  This is very close to what is 
> happening per 2.1, 2.2 of 
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-06
>
> In this case, the Software Statement is an authorization that is 
> exchanged for a client assertion in return. Then the clients 
> authenticate per section 2.2 of the JWT spec.
>
> Regarding initial_access_token.  This does have some of the 
> characteristics I am speaking of. But it is unspecified and the 
> assumption is that it is issued by the local domain.  This doesn't 
> work in the UMA case because that's more like a federated model. Thus 
> the specified software statement works because the AS can approve the 
> client software based on name, and/or developer, and/or publisher -- 
> whatever trust requires.
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>
>
> On 2013-08-28, at 9:29 AM, George Fletcher <[email-masked] 
>> I can't say I understand what you mean by a simple assertion swap... 
>> but if you are wanting to use a client_assertion flow instead of the 
>> code flow then that's something completely different. If you are 
>> saying that you want the client_id to represent an "instance" in a 
>> stateless way using an "assertion" then that's already possible today.
>>
>> George
>>
>>>> I'd argue that almost all user facing mobile apps will want the 
>>>> above flow and that's not a small, rare edge case.
>>>>
>>>> Thanks,
>>>> George
>>>>> position.
>>>>>
>>>>> Phil
>>>>>
>>  <http://connect.me/gffletch>
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 28 Aug 2013 12:41:24 -0400

Yes, that already works. And you could accomplish that with the current 
dynamic registration spec, too -- it's just that client assertions were 
deemed too-underspecified to include in the base draft, and nobody's 
stepped up to offer a full writeup and extension of using other auth 
mechanisms (outside of OpenID Connect).

  -- Justin

On 08/28/2013 12:38 PM, Sergey Beryozkin wrote:
>>>     I agree, in many cases step 1 can be made by simply approving a 
>>> class of software. But then step 2 is simplified.
>>>
>>>
>>>
>>>         Except for the cases where you want step 1 to happen in 
>>> band. To me, that is a vitally and fundamentally important use case 
>>> that we can't disregard, and we must have a solution that can 
>>> accommodate that. The notions of "publisher" and "product" fade very 
>>> quickly once you get outside of the software vendor world.
>>>
>>>
>>>
>>>         This is, of course, not to stand in the way of other 
>>> solutions or approaches (such as something assertion based like 
>>> you're after). It's not a one-or-the-other proposition, especially 
>>> when there are mutually exclusive aspects of each.
>>>
>>>
>>>
>>>         Therefore I once again call for the WG to finish the current 
>>> dynamic registration spec *AND* pursue the assertion based process 
>>> that Phil's talking about. They're not mutually exclusive, let's 
>>> please stop talking about them like they are.
>>>
>>>
>>>
>>>         -- Justin
>>>
>>>
>>>
>>>             1. Software registration/approval. This often happens 
>>> out of band. But in this step policy is defined that approves 
>>> software for use. Many of the reg params are known here.
>>>
>>>
>>>
>>>             Federation techniques come into play as trust approvals 
>>> can be based on developer, product or even publisher.
>>>
>>>
>>>
>>>             2. Each instance associates in a stateless way. Only 
>>> clients that need credential rotation need more.
>>>
>>>
>>>
>>>             Phil
>>>
>>>
>>>
>>>                 I think a certificate based approach is going to 
>>> simplify exchanges in all cases. I encourage the group to explore 
>>> the concept on the call.
>>>
>>>
>>>
>>>                 I am not sure breaking dyn reg up helps. It creates 
>>> yet another option. I would like to explore how federation concept 
>>> in software statements can help with facilitating association and 
>>> making many reg stateless.
>>>
>>>
>>>
>>>                 Phil
>>>
>>>
>>>
>>>                 On 2013-08-28, at 5:43, "Tschofenig, Hannes (NSN - 
>>> FI/Espoo)"<[email-masked]> 
>>> <mailto:[email-masked]>  wrote:
>>>
>>>
>>>
>>>                     We are going to complete the use case 
>>> discussions from last time (Phil wasn't able to walk through all 
>>> slides). Justin was also able to work out a strawman proposal based 
>>> on the discussions last week and we will have a look at it to see 
>>> whether this is a suitable compromise. Here is Justin's mail, in 
>>> case you have missed 
>>> it:http://www.ietf.org/mail-archive/web/oauth/current/msg12036.html
>>>
>>>
>>>
>>>                     Phil, please feel free to make adjustments to 
>>> your slides given the Justin's recent proposal.
>>>
>>>
>>>
>>>                     1. Go 
>>> tohttps://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&PW=NNTI1ZWQzMDJk&RT=MiM0
>>>
>>>                     To add this meeting to your calendar program 
>>> (for example Microsoft Outlook), click this link:
>>>
>>>                     Global dial-in 
>>> Numbers:http://www.nokiasiemensnetworks.com/nvc
>>>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 28 Aug 2013 09:41:53 -0700

Yes. A client could pass the software statement *directly* as its client credential.  Which is one of the *simple* solutions. 8-)

The other case is where the client instance needs its own credential as George indicates.  In that case it could swap the statement for a unique client assertion.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: George Fletcher <[email-masked]>
Date: Wed, 28 Aug 2013 12:43:09 -0400

Thanks for the reference...

We have some deployed implementation that require the use of a 
refresh_token that doesn't seem to be supported by the assertion set of 
specs, but I supposed we could add support for that, though at the 
moment I don't have any pressing requirements to do so.

> client software based on name, and/or developer, and/or publisher -- 
I did not have the same set of assumptions about the 
initial_access_token. Given that we already support federated 
access_tokens (i.e. access tokens issued by different Authorization 
Servers) my assumption around the initial_access_token is that it is 
generated by an entity (local or otherwise) that makes sense for the 
given deployment environment of that application. I would NOT want the 
core spec to be very specific in this regard as it just constrains the 
uses and forces wacky work arounds for use cases not supported by the 
core spec.

---

From: Phil Hunt <[email-masked]>
Date: Wed, 28 Aug 2013 09:43:40 -0700

So why are you fighting so hard against standardizing software assertions?  You're affectively already using the solution for BB+.  

The fact that a standardized initial_access_token eliminates most of the registration endpoint seems to be your primary objection.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-08-28, at 9:41 AM, Justin Richer <[email-masked]> wrote:

> Yes, that already works. And you could accomplish that with the current dynamic registration spec, too -- it's just that client assertions were deemed too-underspecified to include in the base draft, and nobody's stepped up to offer a full writeup and extension of using other auth mechanisms (outside of OpenID Connect).
> 
> -- Justin
>

---

From: John Bradley <[email-masked]>
Date: Wed, 28 Aug 2013 12:45:57 -0400

That is my concern as well, sending an assertion to the authorization endpoint requires a extension of OAuth to add another parameter or placing it in the client_id which you can do now with the dynamic reg spec if the AS wants to. 

Holding up client registration for something that will require an extension to OAuth is overdoing it.   We need something for the OAuth spec we have now without requiring clients implement the assertion flow and other extensions.

John B.

On 2013-08-28, at 12:39 PM, Justin Richer <[email-masked]> wrote:

> The initial_access_token doesn't assume that it's from the local domain. It merely assumes that the authorization server accepts the token, which would be true in the UMA case due to the federation. It could also be the exact same kinds of mechanisms that the software statement would use to achieve federation.
> 
> I still don't see how an auth server is going to know about a client's configuration state with the assertion swap method, since there's no defined mechanism for sending a JWT assertion to the authorization endpoint. 
> 
>  -- Justin
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 28 Aug 2013 12:47:08 -0400

For the last time, I am not against standardizing software assertions. I 
have no idea where you keep getting that idea from, considering how many 
times I've publicly come out in support of it. I've even offered to help 
edit a spec to bring the ideas to their full and proper fruition.

What I disagree with is your conjecture that it eliminates the 
registration and configuration endpoints. It just doesn't, and they can 
work together fine.

Why are you fighting so hard against use cases that can't use or don't 
need software assertions?

  -- Justin

---

From: George Fletcher <[email-masked]>
Date: Wed, 28 Aug 2013 12:47:39 -0400

So Phil... given that you can do all this today with the existing set of 
specifications... why not write the software statements/client assertion 
registration spec so that it meets your use case and deployment needs. 
I'd much rather have two straight forward ways to do something when the 
core use cases are so different than to try and munge everything into 
one and end up with unnecessary complexity in one or both of the solutions.

I see the use case you are trying to solve for as significantly 
different than the one I'm trying to solve for. Now maybe your way is 
the better way but why not let the market make that decision? We will 
not confuse developers by having two ways to do things as it will be 
very clear at the beginning of development which way is needed for their 
use case:)

Thanks,
George

---

From: Phil Hunt <[email-masked]>
Date: Wed, 28 Aug 2013 09:48:38 -0700

You can pass anything as a client_id.  It just has to be accepted. That's the point of us writing a draft here isn't it?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Wed, 28 Aug 2013 12:50:43 -0400

I completely agree with George. I think this is the most sensible way 
forward.

  -- Justin

On 08/28/2013 12:47 PM, George Fletcher wrote:
> So Phil... given that you can do all this today with the existing set 
> of specifications... why not write the software statements/client 
> assertion registration spec so that it meets your use case and 
> deployment needs. I'd much rather have two straight forward ways to do 
> something when the core use cases are so different than to try and 
> munge everything into one and end up with unnecessary complexity in 
> one or both of the solutions.
>
> very clear at the beginning of development which way is needed for 
> their use case:)
>
> Thanks,
> George
>
>> On 2013-08-28, at 9:38 AM, Sergey Beryozkin<[email-masked]>  wrote:
>>
>>>>> George Fletcher<http://connect.me/gffletch>
>>>>>
>>>> --
>>>> George Fletcher<http://connect.me/gffletch>
>>>>
>>>>
>>> Blog:http://sberyozkin.blogspot.com

---

From: Phil Hunt <[email-masked]>
Date: Wed, 28 Aug 2013 09:54:43 -0700

That's what I'm trying to do. All I have been asking for is time to explore the spec and to see how it can impact and simplify dyn reg -- which I believe is a significant amount.  It would be pre-mature at this point to move Dyn Reg forward without exploring this.

I still believe dyn reg is over-specified because it assumes *every* cllient registration is different when in fact 99.9% of registrations are going to fall in clusters of client applications.  Much of the paramaters can be moved to step 1 of registration or at the least be bundled into the software assertion. Thus the reg endpoint only has to deal with truly instance specific details (e.g. like credential management).

I don't pre-clude that most of dyn reg may remain intact, but it seems clear there will be substantive breaking changes that simplify registration.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-08-28, at 9:47 AM, George Fletcher <[email-masked]> wrote:

> So Phil... given that you can do all this today with the existing set of specifications... why not write the software statements/client assertion registration spec so that it meets your use case and deployment needs. I'd much rather have two straight forward ways to do something when the core use cases are so different than to try and munge everything into one and end up with unnecessary complexity in one or both of the solutions.
> 
> I see the use case you are trying to solve for as significantly different than the one I'm trying to solve for. Now maybe your way is the better way but why not let the market make that decision? We will not confuse developers by having two ways to do things as it will be very clear at the beginning of development which way is needed for their use case:)
> 
> Thanks,
> George
>

---

From: George Fletcher <[email-masked]>
Date: Wed, 28 Aug 2013 12:55:16 -0400

OAuth has never specified anything regarding the format the "tokens" 
that the AS has to accept and that's one of it's virtues. It allows for 
many implementations from local only to federated.

I fully believe there is value in defining profiles of OAuth for 
particular problem domains that put restrictions on client_id format, 
access_token format etc (e.g. the assertion set of specs). However, 
those should be layered on top of OAuth as a profile and not be forced 
into the core. Otherwise, we are forcing all implementations down a much 
narrower path than is supported today. I definitely don't want to see 
that happen.

Thanks,
George

On 8/28/13 12:48 PM, Phil Hunt wrote:
> You can pass anything as a client_id.  It just has to be accepted. 
> That's the point of us writing a draft here isn't it?
>
> Phil
>
> @independentid
> On 2013-08-28, at 9:45 AM, John Bradley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> That is my concern as well, sending an assertion to the authorization 
>> endpoint requires a extension of OAuth to add another parameter or 
>> placing it in the client_id which you can do now with the dynamic reg 
>> spec if the AS wants to.
>>
>> Holding up client registration for something that will require an 
>> extension to OAuth is overdoing it.   We need something for the OAuth 
>> spec we have now without requiring clients implement the assertion 
>> flow and other extensions.
>>
>> John B.
>>
>> On 2013-08-28, at 12:39 PM, Justin Richer <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> The initial_access_token doesn't assume that it's from the local 
>>> domain. It merely assumes that the authorization server accepts the 
>>> token, which would be true in the UMA case due to the federation. It 
>>> could also be the exact same kinds of mechanisms that the software 
>>> statement would use to achieve federation.
>>>
>>> I still don't see how an auth server is going to know about a 
>>> client's configuration state with the assertion swap method, since 
>>> there's no defined mechanism for sending a JWT assertion to the 
>>> authorization endpoint.
>>>
>>>  -- Justin
>>>
>>>> It would be reasonable for a client to submit an assertion, and 
>>>> obtain its own client assertion in return.  This is very close to 
>>>> what is happening per 2.1, 2.2 of 
>>>> work in the UMA case because that's more like a federated model. 
>>>> Thus the specified software statement works because the AS can 
>>>> approve the client software based on name, and/or developer, and/or 
>>>> publisher -- whatever trust requires.
>>>>
>>>> Phil
>>>>
>>>> @independentid
>>>> www.independentid.com <http://www.independentid.com/>
>>>>> I can't say I understand what you mean by a simple assertion 
>>>>> swap... but if you are wanting to use a client_assertion flow 
>>>>> instead of the code flow then that's something completely 
>>>>> different. If you are saying that you want the client_id to 
>>>>> represent an "instance" in a stateless way using an "assertion" 
>>>>> then that's already possible today.
>>>>>
>>>>> George
>>>>>
>>>>>>> requires a client_secret in order to retrieve the access token 
>>>>>>> and refresh token, how does the app do this without per app 
>>>>>>> instance registration?
>>>>>>>

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 28 Aug 2013 16:59:58 +0000

>Now maybe your way is the better way but why not let the market make that decision?

So what is the hurry to get the dyn reg specification out the door, if we have the market data it will make the specification that much better. I agree that most of this can be done today w/o any additional specifications, that is what I question the complex, underspecified dyn reg specification that is being proposed.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, August 28, 2013 9:55 AM
To: George Fletcher
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28 Aug, 2pm PDT: Conference Bridge Details

Phil

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

On 2013-08-28, at 9:47 AM, George Fletcher <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
George

Phil

@independentid

www.independentid.com<http://www.independentid.com/>

[email-masked]<mailto:[email-masked]>

On 2013-08-28, at 9:38 AM, Sergey Beryozkin <[email-masked]><mailto:[email-masked]> wrote:

easily.

&code=12345678

Sergey

Thanks,

George

*From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] *On

*To:* Phil Hunt

*Cc:* oauth mailing list

registration?

Thanks,

George

   position.

   Phil

   On 2013-08-28, at 8:41, Justin Richer<[email-masked]><mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]>  wrote:

       -- Justin

           Phil

           On 2013-08-28, at 8:04, Phil Hunt<[email-masked]><mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]>  wrote:

               Phil

               On 2013-08-28, at 5:43, "Tschofenig, Hannes (NSN - FI/Espoo)"<[email-masked]><mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]>  wrote:

                   Meeting Password: oauth

                   4. Click "Join Now".

                   OAuth mailing list

                   [email-masked]<mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]>

               OAuth mailing list

               [email-masked]<mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]>

           OAuth mailing list

           [email-masked]<mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]>

   OAuth mailing list

   [email-masked]<mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]>

--

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

--

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

OAuth mailing list

--

Sergey Beryozkin

Talend Community Coders

Blog: http://sberyozkin.blogspot.com<http://sberyozkin.blogspot.com/>

OAuth mailing list

OAuth mailing list

---

From: Phil Hunt <[email-masked]>
Date: Wed, 28 Aug 2013 10:03:57 -0700

I think many of the parameters in dyn reg need to be specified in the statement -- the main change is we're moving dyn reg parameters into the statement and locking them down between instances.  It keeps hackers from changing individual instances and it minimizes state in per instance registration.

The reason OAuth doesn't have to define token formats is they are largely "local".  Federated token scenarios (like UMA) obviously have to have some OOB agreement on format.  Given that registration in most of these cases is federated, it seems appropriate to define these assertions. (In the non-federated cases (e.g. like Google), they can do registration using workflows with the developer directly.)

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-08-28, at 9:55 AM, George Fletcher <[email-masked]> wrote:

> OAuth has never specified anything regarding the format the "tokens" that the AS has to accept and that's one of it's virtues. It allows for many implementations from local only to federated. 
> 
> I fully believe there is value in defining profiles of OAuth for particular problem domains that put restrictions on client_id format, access_token format etc (e.g. the assertion set of specs). However, those should be layered on top of OAuth as a profile and not be forced into the core. Otherwise, we are forcing all implementations down a much narrower path than is supported today. I definitely don't want to see that happen.
> 
> Thanks,
> George
>

---

From: George Fletcher <[email-masked]>
Date: Wed, 28 Aug 2013 13:07:59 -0400

Could I propose you take a slightly different perspective? Can you build 
a profile using the existing dyn reg spec that provides the capabilities 
you desire and from there determine what doesn't work?

For instance...
    1. initial_access_token contains all non-changing client meta-data
    2. calling the client registration endpoint with the 
initial_access_token causes the AS to recognize the potentially new 
class and store the client class meta-data in the AS (again support for 
local or federated initial_access_token is supported). The client 
specific parameters (possibly redirect URIs or otherwise) are encoded 
into an encrypted assertion and returned as the client_id, no 
client_secret is provided and the registration access token value (which 
again is an encrypted assertion)
    3.  client uses the client_id with either the assertion profile (if 
you want) or the normal OAuth2 core flows (just no secret).

I think that covers what you want to do. This profile of the current 
dyn-reg spec could explicitly disallow certain functions such as the 
update and delete options.

If this spec is much simpler and everyone want to use it, it will be the 
defacto standard anyway. A clean profile is much better than polluting 
the core.

Thanks,
George

On 8/28/13 12:54 PM, Phil Hunt wrote:
> That's what I'm trying to do. All I have been asking for is time to 
> explore the spec and to see how it can impact and simplify dyn reg -- 
> which I believe is a significant amount.  It would be pre-mature at 
> this point to move Dyn Reg forward without exploring this.
>
> I still believe dyn reg is over-specified because it assumes *every* 
> cllient registration is different when in fact 99.9% of registrations 
> are going to fall in clusters of client applications.  Much of the 
> paramaters can be moved to step 1 of registration or at the least be 
> bundled into the software assertion. Thus the reg endpoint only has to 
> deal with truly instance specific details (e.g. like credential 
> management).
>
> I don't pre-clude that most of dyn reg may remain intact, but it seems 
> clear there will be substantive breaking changes that simplify 
> registration.
>
> Phil
>
> @independentid
>> deployment needs. I'd much rather have two straight forward ways to 
>> do something when the core use cases are so different than to try and 
>>>>>> *From:[email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]] *On
>>>>>>                     1. Gotohttps://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&PW=NNTI1ZWQzMDJk&RT=MiM0
>>>>>>

---

From: George Fletcher <[email-masked]>
Date: Wed, 28 Aug 2013 13:14:24 -0400

So, if we take the current OAuth model that I think I hear you 
espousing... OAuth core is "local"  and "federated" scenarios need to be 
profiled to be "locked down" ... then shouldn't we do the same thing 
with the dyn reg spec? Consider what's proposed as "local" and the 
"federated" model is a profile (see my other post).

In the UMA case (as I'm actively involved in that effort) I would want 
the UMA spec to define where agreed upon formats are required. I 
wouldn't want that done in the OAuth core specs. The reason is that the 
specification narrows the scope of the applicabillity of the solution to 
the problem domain being solved. So UMA, which defines the problem space 
it's trying to solve, should be the spec to define the required formats. 
This is clean layering.

In this case of federated app deployments that you are discussing it 
seems like it requires a special profile for that problem domains space 
just as UMA defines it's own profile of OAuth2 for it's problem space 
and OpenID Connect defines it's profile for it's problem domain space.

Thanks,
George

On 8/28/13 1:03 PM, Phil Hunt wrote:
> I think many of the parameters in dyn reg need to be specified in the 
> statement -- the main change is we're moving dyn reg parameters into 
> the statement and locking them down between instances.  It keeps 
> hackers from changing individual instances and it minimizes state in 
> per instance registration.
>
> The reason OAuth doesn't have to define token formats is they are 
> largely "local".  Federated token scenarios (like UMA) obviously have 
> to have some OOB agreement on format.  Given that registration in most 
> of these cases is federated, it seems appropriate to define these 
> assertions. (In the non-federated cases (e.g. like Google), they can 
> do registration using workflows with the developer directly.)
>
> Phil
>
> @independentid
> On 2013-08-28, at 9:55 AM, George Fletcher <[email-masked] 
>> that the AS has to accept and that's one of it's virtues. It allows 
>> for many implementations from local only to federated.
>>
>> those should be layered on top of OAuth as a profile and not be 
>> forced into the core. Otherwise, we are forcing all implementations 
>> down a much narrower path than is supported today. I definitely don't 
>> want to see that happen.
>>
>> Thanks,
>> George
>>
>>>> That is my concern as well, sending an assertion to the 
>>>> authorization endpoint requires a extension of OAuth to add another 
>>>> parameter or placing it in the client_id which you can do now with 
>>>> the dynamic reg spec if the AS wants to.
>>>>
>>>> extension to OAuth is overdoing it.   We need something for the 
>>>> OAuth spec we have now without requiring clients implement the 
>>>> assertion flow and other extensions.
>>>>
>>>> John B.
>>>>
>>>>> domain. It merely assumes that the authorization server accepts 
>>>>> the token, which would be true in the UMA case due to the 
>>>>> federation. It could also be the exact same kinds of mechanisms 
>>>>> that the software statement would use to achieve federation.
>>>>>
>>>>>> assumption is that it is issued by the local domain.  This 
>>>>>> doesn't work in the UMA case because that's more like a federated 
>>>>>> model. Thus the specified software statement works because the AS 
>>>>>> can approve the client software based on name, and/or developer, 
>>>>>> and/or publisher -- whatever trust requires.
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> @independentid
>>>>>>>>> If you have a mobile app that needs to do the code flow... 
>>>>>>>>> which requires a client_secret in order to retrieve the access 
>>>>>>>>> token and refresh token, how does the app do this without per 
>>>>>>>>> app instance registration?
>>>>>>>>>
>>>>>>>>> I'd argue that almost all user facing mobile apps will want 
>>>>>>>>> the above flow and that's not a small, rare edge case.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> George
>>>>>>>>>> position.
>>>>>>>>>>
>>>>>>>>>> Phil
>>>>>>>>>>

---

From: "Donald F Coffin" <[email-masked]>
Date: Wed, 28 Aug 2013 10:17:30 -0700

+1

Best regards,
Don
Donald F. Coffin
Founder/CTO

REMI Networks
22751 El Prado Suite 6216
Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571
Email:       [email-masked]

-----Original Message-----
From: Justin Richer [mailto:[email-masked]] 
Sent: Wednesday, August 28, 2013 8:42 AM
To: Phil Hunt
Cc: oauth mailing list
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call: Wed 28
Aug, 2pm PDT: Conference Bridge Details

Except for the cases where you want step 1 to happen in band. To me, that is
a vitally and fundamentally important use case that we can't disregard, and
we must have a solution that can accommodate that. The notions of
"publisher" and "product" fade very quickly once you get outside of the
software vendor world.

This is, of course, not to stand in the way of other solutions or approaches
(such as something assertion based like you're after). It's not a
one-or-the-other proposition, especially when there are mutually exclusive
aspects of each.

  -- Justin

On 08/28/2013 11:17 AM, Phil Hunt wrote:
> 1. Software registration/approval. This often happens out of band. But in
this step policy is defined that approves software for use. Many of the reg
params are known here.
>> I think a certificate based approach is going to simplify exchanges in
all cases. I encourage the group to explore the concept on the call.
>>
>> I am not sure breaking dyn reg up helps. It creates yet another option. I
would like to explore how federation concept in software statements can help
with facilitating association and making many reg stateless.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 28 Aug 2013 13:14:08 -0600

Not everyone has the time or inclination to follow and respond to all of this.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 29 Aug 2013 07:41:53 +0200

Authz server and resource server need to agree on a token format. The client never needs to interpret the token content. Since we are talking about clients, where is the connection? 

regards,
Torsten.

Phil Hunt <[email-masked]> schrieb:
>assertions. (In the non-federated cases (e.g. like Google), they can do
>registration using workflows with the developer directly.)
>
>Phil
>
>@independentid
>www.independentid.com
>[email-masked]
>
>
>
>
>
>
>
>into the core. Otherwise, we are forcing all implementations down a
>much narrower path than is supported today. I definitely don't want to
>see that happen.
>> 
>> Thanks,
>> George
>> 
>parameter or placing it in the client_id which you can do now with the
>dynamic reg spec if the AS wants to. 
>>>> 
>spec we have now without requiring clients implement the assertion flow
>and other extensions.
>>>> 
>>>> John B.
>>>> 
>obtain its own client assertion in return.  This is very close to what
>is happening per 2.1, 2.2 of
>assumption is that it is issued by the local domain.  This doesn't work
>in the UMA case because that's more like a federated model. Thus the
>specified software statement works because the AS can approve the
>swap... but if you are wanting to use a client_assertion flow instead
>of the code flow then that's something completely different. If you are
>>>>>>>>>> I agree, in many cases step 1 can be made by simply approving
>a class of software. But then step 2 is simplified. 
>>>>>>>>>> 
>which requires a client_secret in order to retrieve the access token
>and refresh token, how does the app do this without per app instance
>registration? 
>>>>>>>>> 
>solutions or approaches (such as something assertion based like you're
>after). It's not a one-or-the-other proposition, especially when there
>are mutually exclusive aspects of each.
>>>>>>>>>>> 
>dynamic registration spec *AND* pursue the assertion based process that
>Phil's talking about. They're not mutually exclusive, let's please stop
>talking about them like they are.
>>>>>>>>>>> 
>>>>>>>>>>> -- Justin
>>>>>>>>>>> 
>>>>>>>>>>>> 1. Software registration/approval. This often happens out
>of band. But in this step policy is defined that approves software for
>use. Many of the reg params are known here.
>>>>>>>>>>>> 
>>>>>>>>>>>> Federation techniques come into play as trust approvals can
>be based on developer, product or even publisher.
>>>>>>>>>>>> 
>>>>>>>>>>>>> I think a certificate based approach is going to simplify
>exchanges in all cases. I encourage the group to explore the concept on
>the call.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I am not sure breaking dyn reg up helps. It creates yet
>another option. I would like to explore how federation concept in
>software statements can help with facilitating association and making
>many reg stateless.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Phil
>>>>>>>>>>>>> 
>FI/Espoo)" <[email-masked]> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> We are going to complete the use case discussions from
>last time (Phil wasn't able to walk through all slides). Justin was
>also able to work out a strawman proposal based on the discussions last
>week and we will have a look at it to see whether this is a suitable
>https://nsn.webex.com/nsn/j.php?ED=269567657&UID=0&PW=NNTI1ZWQzMDJk&RT=MiM0
>------------------------------------------------------------------------
>