Subject: [OAUTH-WG] draft-hunt-oauth-client-association-00

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 01 Nov 2013 20:01:05 +0100

Hi Phil, Hi Tony, Hi all,

I re-read the document and I believe the most important concept it 
introduces is the classification of different associations, namely into 
'static', 'dynamic', and 'transient'. This is certainly something 
worthwhile to discuss during the meeting and to ensure that it is well 
understood, and that there are only these three classes (rather than two 
or four).

The description in the introduction makes the differentiation between 
the three concepts mostly based on how the endpoints are configured in 
the application.

With the static association the endpoint is hard-coded into the software 
during the development time. It cannot be changed. With the two other 
cases the endpoint can be changed. As such, the difference between the 
'dynamic', and 'transient' association seems to be in the terms of how 
long the lifetime of the association. Now, what exactly is the lifetime 
of an association? Is the lifetime of the association understood as the 
lifetime of the configured endpoint identifier?

Then, when I re-read the text in Section 1 again then I suddenly get the 
impression that the lifetime of the association actually does not matter 
but instead the difference is rather whether the client is public or 
confidential. Is that true?

If it isn't true that this is the feature that makes the distinction 
between 'dynamic', and 'transient' then the notion of "public" vs. 
"confidential" client isn't too important for the rest of the document.

Ciao
Hannes

---

From: Phil Hunt <[email-masked]>
Date: Fri, 1 Nov 2013 12:56:11 -0700

Hannes,

Great timing!

This is an aspect that I think deserves more discussion. One of the challenges was to draw a clear line of distinction between transient and dynamic.  

Transient clients are really meant for javascript clients that decide to connect to a particular end-point on the fly.  Note you can still have "static" javascript clients that are hard coded to connect and have already received a client_id through an out-of-band process.

Phil

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

On 2013-11-01, at 12:01 PM, Hannes Tschofenig <[email-masked]> wrote:

> I re-read the document and I believe the most important concept it introduces is the classification of different associations, namely into 'static', 'dynamic', and 'transient'. This is certainly something worthwhile to discuss during the meeting and to ensure that it is well understood, and that there are only these three classes (rather than two or four).
> 
> The description in the introduction makes the differentiation between the three concepts mostly based on how the endpoints are configured in the application.
> 
> With the static association the endpoint is hard-coded into the software during the development time. It cannot be changed. With the two other cases the endpoint can be changed. As such, the difference between the 'dynamic', and 'transient' association seems to be in the terms of how long the lifetime of the association. Now, what exactly is the lifetime of an association? Is the lifetime of the association understood as the lifetime of the configured endpoint identifier?
> 
> Then, when I re-read the text in Section 1 again then I suddenly get the impression that the lifetime of the association actually does not matter but instead the difference is rather whether the client is public or confidential. Is that true?
> 
> If it isn't true that this is the feature that makes the distinction between 'dynamic', and 'transient' then the notion of "public" vs. "confidential" client isn't too important for the rest of the document.
> 
> Ciao
> Hannes
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 01 Nov 2013 21:23:09 +0100

Hi Phil,

We definitely have to figure out how the differentiation is made so that
a developer (or someone who deploys the technology) understands the
scenario they are in and what the implications are. At the moment I
would struggle a bit.

Using examples is certainly a good idea, like you did below. There are,
however, quickly challenges. For example, in the JavaScript case below
you can imagine a developer of a smart phone app who uses JavaScript but
then packages the application (using PhoneGap), which makes it behave
very much like a native app.

And, as you say below, the notion of whether the endpoint is configured 
upfront (during development time) or dynamically configured may not 
necessarily matter.

It definitely makes sense to discuss this during the meeting and 
real-world examples may help.

Ciao
Hannes

Am 01.11.13 20:56, schrieb Phil Hunt:
> Hannes,
>
> Great timing!
>
> This is an aspect that I think deserves more discussion. One of the
> challenges was to draw a clear line of distinction between transient
> and dynamic.
>
> Transient clients are really meant for javascript clients that decide
> to connect to a particular end-point on the fly.  Note you can still
> have "static" javascript clients that are hard coded to connect and
> have already received a client_id through an out-of-band process.
>
> Phil
>
> @independentid www.independentid.com [email-masked]
>
>> introduces is the classification of different associations, namely
>> into 'static', 'dynamic', and 'transient'. This is certainly
>> something worthwhile to discuss during the meeting and to ensure
>> that it is well understood, and that there are only these three
>> classes (rather than two or four).
>>
>> The description in the introduction makes the differentiation
>> between the three concepts mostly based on how the endpoints are
>> configured in the application.
>>
>> With the static association the endpoint is hard-coded into the
>> software during the development time. It cannot be changed. With
>> the two other cases the endpoint can be changed. As such, the
>> difference between the 'dynamic', and 'transient' association seems
>> to be in the terms of how long the lifetime of the association.
>> Now, what exactly is the lifetime of an association? Is the
>> lifetime of the association understood as the lifetime of the
>> configured endpoint identifier?
>>
>> Then, when I re-read the text in Section 1 again then I suddenly
>> get the impression that the lifetime of the association actually
>> does not matter but instead the difference is rather whether the
>> client is public or confidential. Is that true?
>>
>> If it isn't true that this is the feature that makes the
>> distinction between 'dynamic', and 'transient' then the notion of
>> "public" vs. "confidential" client isn't too important for the rest
>> of the document.
>>
>> Ciao Hannes
>>
>>
>> _______________________________________________ OAuth mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 1 Nov 2013 15:02:21 -0700

I think for the client types, the trick is to try to make it restrictive enough so there's no second-guessing the client developer has to do about what SPs will accept.  The line I was drawing was for implicit/javascript clients in the current draft.

We could open it to a simple decision for the client developer.  If they think they will need an instance specific client_id from service endpoints, then they need to use dynamic registration.  Otherwise transient registration could be used for on-the-fly transient associations - which are still public clients.

My assessment was we could keep transient restricted to implicit/javascript only - making the choice very clear.  But I'd love to hear if someone has a case where they think transient fits a client doing one of the other authorization flows (the broader case).

BTW….this is why the client association draft is in fact so long.  There is considerable text discussing the classifications and their differences.

Looking at it now, I'm starting to feel stricter "normative" text (MUSTs & SHOULDS) and less fuzzy explanation and/or examples might actually be better for inter-op and perceived simplicity/clarity.

Phil

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

On 2013-11-01, at 1:23 PM, Hannes Tschofenig <[email-masked]> wrote:

> And, as you say below, the notion of whether the endpoint is configured upfront (during development time) or dynamically configured may not necessarily matter.
> 
> It definitely makes sense to discuss this during the meeting and real-world examples may help.
> 
> Ciao
> Hannes
>

---

From: Josh Mandel <[email-masked]>
Date: Fri, 1 Nov 2013 18:42:19 -0400

Hi Justin,

Well, I spent ~20min to read over this pair of drafts (association +
software_statement). I have to say that in isolation, I find this approach
quite reasonable. In particular:

1. This approach does *not* require both a bearer token and
software_statement for the registration step. The software_statement alone
should work for a case lke B. (Bearer token is only presented to the
registration endpoint for refresh/update -- or if some out of band authz
needs to be communicated.)

2. This approach is very friendly for public ("transient") clients.  No
need to delete/expire/repeat the regsitration.

Under this spec, a BB+ Registry would produce software_statements instead
of preregistration_jwts, but otherwise works the same.

I'm definitely interested to hear what you see as the drawbacks

  -J

---------- Forwarded message ----------
From: Phil Hunt <[email-masked]>
Date: Fri, Nov 1, 2013 at 6:02 PM
Subject: Re: [OAUTH-WG] draft-hunt-oauth-client-association-00
To: Hannes Tschofenig <[email-masked]>
Cc: "[email-masked] WG" <[email-masked]>

I think for the client types, the trick is to try to make it restrictive
enough so there's no second-guessing the client developer has to do about
what SPs will accept.  The line I was drawing was for implicit/javascript
clients in the current draft.

We could open it to a simple decision for the client developer.  If they
think they will need an instance specific client_id from service endpoints,
then they need to use dynamic registration.  Otherwise transient
registration could be used for on-the-fly transient associations - which
are still public clients.

My assessment was we could keep transient restricted to implicit/javascript
only - making the choice very clear.  But I'd love to hear if someone has a
case where they think transient fits a client doing one of the other
authorization flows (the broader case).

BTW….this is why the client association draft is in fact so long.  There is
considerable text discussing the classifications and their differences.

Looking at it now, I'm starting to feel stricter "normative" text (MUSTs &
SHOULDS) and less fuzzy explanation and/or examples might actually be
better for inter-op and perceived simplicity/clarity.

Phil

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Sun, 3 Nov 2013 04:41:51 +0000

The software statement does make sense and we could use it in BB+ to take the place of the registration_jwt, even though I'm not really in favor of inventing yet another mechanism for presenting an assertion to an OAuth-protected endpoint.

The association draft is in many ways semantically equivalent to the existing dynamic registration draft, but less flexible and it overloads the token endpoint.

 -- Justin

On Nov 1, 2013, at 6:42 PM, Josh Mandel <[email-masked]<mailto:[email-masked]>>
 wrote:

Hi Justin,

Well, I spent ~20min to read over this pair of drafts (association + software_statement). I have to say that in isolation, I find this approach quite reasonable. In particular:

1. This approach does *not* require both a bearer token and software_statement for the registration step. The software_statement alone should work for a case lke B. (Bearer token is only presented to the registration endpoint for refresh/update -- or if some out of band authz needs to be communicated.)

2. This approach is very friendly for public ("transient") clients.  No need to delete/expire/repeat the regsitration.

Under this spec, a BB+ Registry would produce software_statements instead of preregistration_jwts, but otherwise works the same.

  -J

---------- Forwarded message ----------
From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Fri, Nov 1, 2013 at 6:02 PM
Subject: Re: [OAUTH-WG] draft-hunt-oauth-client-association-00
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]> WG" <[email-masked]<mailto:[email-masked]>>

Phil

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

On 2013-11-01, at 1:23 PM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

>> @independentid www.independentid.com<http://www.independentid.com/> [email-masked]<mailto:[email-masked]>
>>
>> On 2013-11-01, at 12:01 PM, Hannes Tschofenig
>> <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/oauth
>>
>

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

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

---

From: Phil Hunt <[email-masked]>
Date: Sat, 2 Nov 2013 22:28:21 -0700

Client assoc is a profile of the existing token endpoint and uses the assertion drafts definition of client assertion. As such it is not a new mechanism. 

Client assoc is also compatible with assertion draft and thus as new token formats are defined they can automatically be issued via dyn association without amending client assoc draft or profiling each time. 

Phil

> On Nov 2, 2013, at 21:41, "Richer, Justin P." <[email-masked]> wrote:
> 
> On Nov 1, 2013, at 6:42 PM, Josh Mandel <[email-masked]>
>  wrote:
> 
>> Hi Justin,
>> 
>> >> <[email-masked]> wrote:
>> >>