Subject: [OAUTH-WG] Dynamic Client Registration Conference Call - Meeting Minutes (22. Aug)

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 23 Aug 2013 10:24:32 +0200

Thank you all for joining yesterday's conference call. I took some notes 
during the call.

---- Meeting Minutes ----

Participants:
- William Kim
- John Bradley
- Antonio Sanso
- Mike Jones
- Phil Hunt
- Justin Richer
- Hannes Tschofenig
- Derek Atkins
- Amanda Anganes
- Morteza Ansari
- Brian Campbell
- Thomas Hardjono
- Prateek Mishra
- George Fletcher
- Tony Nadalin

Minutes

Justin started with a discussion about what is described in Section 1.3 
of the protocol specification and Appendix B describes the use cases.

Dynamic client registration is one way to introduce a client to an 
authorization server.
A client is the relationship between a client piece software and a piece 
of software on the authorization server side.
The client needs a client_id and the authorization server needs to get 
various other piece of information (such as a redirect_uri, display_name).

The group then started a discussion about what the minimal amount of 
information is the authorization server needs to have.

The discussion then shifted to uses cases where trust is established 
a-priori (out-of-band) and is conveyed via an assertion to the dyn-reg 
exchange (protected registration) and the case where there is no trust 
(=open registration); the latter case would push the obligation to the 
user.

There seems to be agreement (on the call) that both use cases are valid.

The following examples for protected registration have been discussed:

  * manual page where the developer obtains a developer key and register 
there; they end up with an initial access token (in the form of an 
bearer token)
  * UMA case where there is someone who is introducing the two parties 
to each other. (Currently not described in the document)
  * Developer Automation: Who holds the client registration information? 
The developer makes the call and you get the client_id back. The client 
is not doing the dyn. registration. (This use case is described in 
Appendix B.3)
  * John's use case: 
http://www.ietf.org/mail-archive/web/oauth/current/msg12008.html

Phil Hunt starts with his presentation slides, which he had distributed 
to the mailing list earlier:
http://www.ietf.org/mail-archive/web/oauth/current/msg12007.html

Phil says that the client_id does not need to be provided by the AS - it 
could be provided by the client. John says that the client_id has to be 
tied to the redirect_uri since otherwise attacks are possible.

Phil says we are lacking good terminology for client, and for client 
instance.

George claims that the client instance concept came up when mobile 
clients and Web clients got mixed in deployments and people wanted to 
have a way to distinguish the two since they were different in their 
ability to keep a secret.

A discussion started about whether an evolution had happened regarding 
different types of clients. The client id is a proxy for some release of 
some software. Someone claimed that with dynamic client registration we 
have the ability to turn public clients back into confidential clients.

Phil argues that service providers want to know the class of 
applications and the instances. A problem with a client can be a 
compromise and you want to disable it. There may also be a bug in the 
software and then one may want to disable the entire class of clients.

Phil asks whether we expect that JavaScript code registers every time 
the code runs. The response was clear that this is not the expectation.

Phil then goes on to explain four levels of dynamic behavior:

  * Client developer hardcodes the address of the authorization server 
and other information.
  * Developer may hardcode some information but the client may 
dynamically interact with the authorization server to provide additional 
information (suggested by John)
  * Confirmation information in the client software can be used to 
dertermine which server to talk to and which parameters to use
  * Client software decides at runtime who to contact and what 
information to provide

Hannes stopped the discussion because we ran out of time and started a 
discussion about where we could go next.

Justin said that he has not seen anything that is not supported yet.
Tony, Phil, and Prateek say that we are trying to find the minimum 
supported information.

It seems that different folks have different use cases in mind. Can this 
situation be solved with extensions? Phil claims that the current 
specification is overly complex.

It is clear that we cannot have one single spec that covers all the use 
cases.
Are we arguing which use cases are covered in the base specification?

Tony suggested that only client_id and redirect_uri should be the 
supported and everything else should be dropped.

Justin responded that the rest is optional anyway.

Discussion started about what "optional" means. Does the authorization 
server have to implement to implement even optional components?

John says that we need a new feature for adding and removing a new 
endpoint. This is a common use case and we don't want to revoke all the 
permissions when we do so.

Mike says that there is some additional material needed beyond client_id 
and redirect_uri.
John agrees.

Prateek says that we need to identify a minimal subset and have 
extensions defined.

Hannes will talk to Derek about the next steps. Expect another 
conference call soon.

Phil will update the software assertion document.

---

From: Antonio Sanso <[email-masked]>
Date: Fri, 23 Aug 2013 09:55:53 +0100

Hi Hannes,

thanks a lot for your notes.

As suggested from you guys yesterday I'd like to bring on my little point :) (that is really orthogonal to the whole discussion).

IMHO since the dynamic registration is still on a design phase it would be really nice to include something that Google already implemented in order to allow server-to-server communication [0].

In order to allow this, in the registration phase, there is the option to download a private key (in order to allow the client to sign self produced signed JWT without 'human interaction'), quoting [0]

"During the creation of a Service Account, you will be prompted to download a private key. Be sure to save this private key in a secure location. After the Service Account has been created, you will also have access to the client_id associated with the private key." 

IMHO this is a really clever way to use OAuth and would be nice to see this standardized and having it on the big picture. Obviously this should be just an optional field.

Just my 0.02 $

Thanks and regards

Antonio

[0] https://developers.google.com/accounts/docs/OAuth2ServiceAccount

On Aug 23, 2013, at 10:24 AM, Hannes Tschofenig wrote:

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

---

From: "Anganes, Amanda L" <[email-masked]>
Date: Fri, 23 Aug 2013 12:46:24 +0000

Thanks for the notes, Hannes.

I didn't speak up on the call at all because it honestly left me a bit
confused. For the first 3/4 or so I was trying to figure out what the
problem was that everyone was fighting about. Phil, Tony, and others
seemed to be pointing out that "in all of these cases that we can tell you
about, it doesn't make sense to do DynReg". That is fine. That's not a
problem; that just reflects the fact that there are different use cases
out there that may not need this OPTIONAL part of the spec suite.

After that there seemed to be some consensus (at least among those that
were bringing up the original complaints) that folks would like to see a
smaller core document, with all of the optional parts removed to one or
more extensions. I'll grant that the DynReg draft has gotten long and
there are a lot of optional pieces. Maybe it makes sense to break it out;
at the very least I think it's worth trying. Perhaps more of the WG would
accept it if that was the case.

I believe Tony commented that "if something is optional, it means that ALL
servers everywhere have to support it". I don't understand that - the
requirement for servers to ignore (i.e., don't throw an error or fall
over) if a client sends over a parameter it doesn't understand has always
been part of the core OAuth 2.0 spec. It's not a new idea.

There was also a comment that the WG doesn't have a lot of experience with
this domain. That's true, but the experience the WG *does* have is with
the UMA and OIDC use cases, which directly fed into the current draft.
DynReg v14 is sufficient for the two major classes of *real*, deployed and
under development, non-hypothetical use cases that we know of today. We
can't loose sight of this fact.

If there is something missing from the current draft, or something present
that disallows a particular requirement, I'd ask the other WG members to
please present those requirements and problems clearly so that we can
discuss them. So far I haven't seen anything concrete in this area. I've
heard a lot of contention and fighting but I can't make out what the
actual problem statement is. Phil's software statements/assertions seems
to fit well as an extension; it's not prohibited by anything existing in
the draft. 

*apologies if I misattributed comments; I can recognize most of the voices
that were on the call but not all of them.

--Amanda

---

From: George Fletcher <[email-masked]>
Date: Fri, 23 Aug 2013 11:48:05 -0400

Description of the run-time registration use case I was discussing on 
the phone yesterday.

Consider a protected resource that supports multiple Authorization 
Services run by different organizations (i.e. not in the same domain). 
This protected resource will honor an access_token issued by the 
different Authorization Servers.

There is a client app (possibly built by a 3rd party) using the 
protected resource APIs that wants to support the largest number of 
users possible.

Run-time flow includes...
1. determine which AS is appropriate for a given user (could leverage 
webfinger)
2. dynamically register the client with the AS (one time only but done 
on an as needed basis)
3. go through the authorization flow to obtain an access token
4. present the access token to the protected resource

This model allows the client developer (and client app) to be agnostic 
to any back channel relationships between the Authorization Servers and 
the Protected Resource. A new AS could be added to the over all eco 
system and the client would not need to change.

Note that we do have a partner client deployed that effectively supports 
two different Authorization Servers both authorized to issue tokens for 
a protected resource at AOL. Not all of the current implementation is 
OAuth2 compatible, but the use case described above is where I want this 
capability to evolve to.

Note that the UMA case is similar...

1. requesting client attempts to access a protected resource
2. protected resource rejects access and informs the requesting client 
they need to get authorization from a particular UMA Authorization Manager
3. requesting client discovers endpoints at the designated UMA 
Authorization manager
4. requesting client dynamically registers with the Authorization 
Manager (if it hasn't already)
5. requesting client obtains an OAuth access token representing the 
user:requesting client:AS for use in helping the user provide claims to 
satisfy the UMA authorization policy for the protected resource
6. ... [rest of UMA flow]

Thanks,
George

On 8/23/13 4:24 AM, Hannes Tschofenig wrote:
> Thank you all for joining yesterday's conference call. I took some 
> notes during the call.
>
> Justin started with a discussion about what is described in Section 
> 1.3 of the protocol specification and Appendix B describes the use cases.
>
> A client is the relationship between a client piece software and a 
> piece of software on the authorization server side.
>  * manual page where the developer obtains a developer key and 
> register there; they end up with an initial access token (in the form 
> of an bearer token)
>  * Developer Automation: Who holds the client registration 
> information? The developer makes the call and you get the client_id 
> back. The client is not doing the dyn. registration. (This use case is 
> described in Appendix B.3)
>  * John's use case: 
> Phil Hunt starts with his presentation slides, which he had 
> distributed to the mailing list earlier:
> Phil says that the client_id does not need to be provided by the AS - 
> it could be provided by the client. John says that the client_id has 
> to be tied to the redirect_uri since otherwise attacks are possible.
>
> different types of clients. The client id is a proxy for some release 
> of some software. Someone claimed that with dynamic client 
> registration we have the ability to turn public clients back into 
> confidential clients.
>
> dynamically interact with the authorization server to provide 
> additional information (suggested by John)
> It seems that different folks have different use cases in mind. Can 
> this situation be solved with extensions? Phil claims that the current 
> It is clear that we cannot have one single spec that covers all the 
> use cases.
> endpoint. This is a common use case and we don't want to revoke all 
> the permissions when we do so.
>
> Mike says that there is some additional material needed beyond 
> client_id and redirect_uri.
> John agrees.
>

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

---

From: John Bradley <[email-masked]>
Date: Fri, 23 Aug 2013 12:16:09 -0400

We have that in the OIDC version where the client publishes it's public key.  That is in general better from a security point of view if you believe clients can securely generate key pairs.

It is not in the IETF version because we were asked not to include authentication methods not defined in the core spec, as they were thought best to be extensions.  

It currently looks like the pressure is on to remove confuguration options rather than add them.

I agree that client registration is a reasonable place to exchange keys and avoid having symmetric secrets,  that is the preferred OIDC implementation for clients that can support it.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 23 Aug 2013 09:39:51 -0700

Hmmm. We are defining token drafts that discuss key distribution. Part of my objection is that doing a different method in reg not only overloads reg but complicates key mgmt. 

Phil

On 2013-08-23, at 9:16, John Bradley <[email-masked]> wrote:

> <smime.p7s>

---

From: Antonio Sanso <[email-masked]>
Date: Fri, 23 Aug 2013 17:42:18 +0100

Thanks a lot John for your answer. 

How about the server to server flow per se as in [0].

Is it standardized anywhere (OAuth/OIDC)? Or is just custom at Google?

I think this is kind of clever and really suites case where there is not "human interaction"

regards

Antonio

________________________________________
From: John Bradley [[email-masked]]
Sent: 23 August 2013 18:16
To: Antonio Sanso
Cc: Hannes Tschofenig; [email-masked] WG
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call - Meeting Minutes (22. Aug)

John B.

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 23 Aug 2013 16:23:06 +0000

>I believe Tony commented that "if something is optional, it means that ALL servers everywhere have to support it". I don't understand that - the requirement for servers to ignore (i.e., don't throw an error or fall
over) if a client sends over a parameter it doesn't understand has always been part of the core OAuth 2.0 spec. It's not a new idea.

So servers have to code to prevent unwanted behavior from happening, so the more that is in the spec that is optional that the server does not want to support the more the server side has to deal with failing, ignoring, etc. It makes more sense to chunk this up into a basic registration message and response and then extensions for all the stuff that that go beyond the simple registration process. OIDC can't just pick this up and use it as is, there are still specific requirements that OIDC needs beyond this and different from this proposal, so the I believe that we could get agreement on the basic registration messages and let the other groups do the specific extensions they need. 

As I have stated most of the dynamic registration draft goes beyond the scope of this WG dealing with client configuration and management. We have stayed well away from client authentication methods and we should stay well away from client configuration and management.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Anganes, Amanda L
Sent: Friday, August 23, 2013 5:46 AM
To: Hannes Tschofenig; [email-masked] WG
Subject: Re: [OAUTH-WG] Dynamic Client Registration Conference Call - Meeting Minutes (22. Aug)

I didn't speak up on the call at all because it honestly left me a bit confused. For the first 3/4 or so I was trying to figure out what the problem was that everyone was fighting about. Phil, Tony, and others seemed to be pointing out that "in all of these cases that we can tell you about, it doesn't make sense to do DynReg". That is fine. That's not a problem; that just reflects the fact that there are different use cases out there that may not need this OPTIONAL part of the spec suite.

After that there seemed to be some consensus (at least among those that were bringing up the original complaints) that folks would like to see a smaller core document, with all of the optional parts removed to one or more extensions. I'll grant that the DynReg draft has gotten long and there are a lot of optional pieces. Maybe it makes sense to break it out; at the very least I think it's worth trying. Perhaps more of the WG would accept it if that was the case.

I believe Tony commented that "if something is optional, it means that ALL servers everywhere have to support it". I don't understand that - the requirement for servers to ignore (i.e., don't throw an error or fall
over) if a client sends over a parameter it doesn't understand has always been part of the core OAuth 2.0 spec. It's not a new idea.

There was also a comment that the WG doesn't have a lot of experience with this domain. That's true, but the experience the WG *does* have is with the UMA and OIDC use cases, which directly fed into the current draft.
DynReg v14 is sufficient for the two major classes of *real*, deployed and under development, non-hypothetical use cases that we know of today. We can't loose sight of this fact.

If there is something missing from the current draft, or something present that disallows a particular requirement, I'd ask the other WG members to please present those requirements and problems clearly so that we can discuss them. So far I haven't seen anything concrete in this area. I've heard a lot of contention and fighting but I can't make out what the actual problem statement is. Phil's software statements/assertions seems to fit well as an extension; it's not prohibited by anything existing in the draft. 

*apologies if I misattributed comments; I can recognize most of the voices that were on the call but not all of them.

--Amanda

On 8/23/13 4:24 AM, "Hannes Tschofenig" <[email-masked]> wrote:

>it could be provided by the client. John says that the client_id has to 
>be tied to the redirect_uri since otherwise attacks are possible.
>
>of some software. Someone claimed that with dynamic client registration 
>we have the ability to turn public clients back into confidential clients.
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 23 Aug 2013 10:14:31 -0700

Two ways to handle complexity here.

Reading over the minutes, I'm not sure it was clear the main point of observation I am trying to make to the group.

The current design assumes that every client is somehow completely different as the majority standing. This has lead to a design where all protocol related values and informational values must be provided at "association" time.   We've tried to apply this specification with this model against a number of use cases, and my chief problem is three-fold:
1.  Amount of data that must be retained per client (with no way to tell for how long)
2.  On a per client basis, it is unclear what each client must do to successfully register.  The spec presumes a lot of prior knowledge as to what is required and what isn't.  
3. Instead of just issuing one credential (client cred), the spec issues 2 and defines another.  Three special case security credentials each with special handling.

I have no doubt that many have successfully implemented this. But the concern is that the number of APIs tested and in production is extremely low.

I am proposing 2 observations that MAY make the eventual solution much much much easier to implement and operate.
a.  In most cases, client software is not custom. Custom software is an edge case (that must be supported).  Most client software can be grouped together as software distributions (software downloaded from a common site as a common distribution).  If we call this a software 'class', then we can observe that for a particular software class, there MAY be one or more instances of a class associating with any particular AS.  For any particular AS, the only thing that might change about the client is the redirect_url -- and this is likely only for web apps, not native apps.

b. If you look at the categories I presented yesterday, and in particular the last slide. You can notice that the solution for each category is relatively trivial and clearly defined. Categorization of clients seems like complexity at first. But once you look at it, you see that the decision path for developers is very clear.  Once a developer decides what type they are, the methodology is clear.

Finally, I believe that re-framing into "classes" and "categories" will also handle, in a better way, the cases for UMA and OIDC which are also at one end of a spectrum of associations (static vs. dynamic). At one end, static clients are hard-coded to a particular AS, next clients that associate upon installation, to OIDC clients that associate on an ongoing configuration basis (like imap clients), to UMA which may associate on a per-event basis.

To avoid more discussion continuing to go in circles, it seems time I put forward a draft for the group to consider. While this may present changes to the method of registration, I hope you will agree that it is much simpler.

Thanks in advance for your patience, thoughts, and ideas.

Phil

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

On 2013-08-23, at 1:24 AM, Hannes Tschofenig <[email-masked]> wrote:

> Thank you all for joining yesterday's conference call. I took some notes during the call.
> 
> Justin started with a discussion about what is described in Section 1.3 of the protocol specification and Appendix B describes the use cases.
> 
> Dynamic client registration is one way to introduce a client to an authorization server.
> A client is the relationship between a client piece software and a piece of software on the authorization server side.
> The client needs a client_id and the authorization server needs to get various other piece of information (such as a redirect_uri, display_name).
> 
> The group then started a discussion about what the minimal amount of information is the authorization server needs to have.
> 
> The discussion then shifted to uses cases where trust is established a-priori (out-of-band) and is conveyed via an assertion to the dyn-reg exchange (protected registration) and the case where there is no trust (=open registration); the latter case would push the obligation to the user.
> 
> * manual page where the developer obtains a developer key and register there; they end up with an initial access token (in the form of an bearer token)
> * UMA case where there is someone who is introducing the two parties to each other. (Currently not described in the document)
> * Developer Automation: Who holds the client registration information? The developer makes the call and you get the client_id back. The client is not doing the dyn. registration. (This use case is described in Appendix B.3)
> * John's use case: http://www.ietf.org/mail-archive/web/oauth/current/msg12008.html
> 
> Phil Hunt starts with his presentation slides, which he had distributed to the mailing list earlier:
> Phil says that the client_id does not need to be provided by the AS - it could be provided by the client. John says that the client_id has to be tied to the redirect_uri since otherwise attacks are possible.
> 
> Phil says we are lacking good terminology for client, and for client instance.
> 
> George claims that the client instance concept came up when mobile clients and Web clients got mixed in deployments and people wanted to have a way to distinguish the two since they were different in their ability to keep a secret.
> 
> A discussion started about whether an evolution had happened regarding different types of clients. The client id is a proxy for some release of some software. Someone claimed that with dynamic client registration we have the ability to turn public clients back into confidential clients.
> 
> Phil argues that service providers want to know the class of applications and the instances. A problem with a client can be a compromise and you want to disable it. There may also be a bug in the software and then one may want to disable the entire class of clients.
> 
> Phil asks whether we expect that JavaScript code registers every time the code runs. The response was clear that this is not the expectation.
> 
> * Client developer hardcodes the address of the authorization server and other information.
> * Developer may hardcode some information but the client may dynamically interact with the authorization server to provide additional information (suggested by John)
> * Confirmation information in the client software can be used to dertermine which server to talk to and which parameters to use
> * Client software decides at runtime who to contact and what information to provide
> 
> Hannes stopped the discussion because we ran out of time and started a discussion about where we could go next.
> 
> Tony, Phil, and Prateek say that we are trying to find the minimum supported information.
> 
> It seems that different folks have different use cases in mind. Can this situation be solved with extensions? Phil claims that the current specification is overly complex.
> 
> It is clear that we cannot have one single spec that covers all the use cases.
> Tony suggested that only client_id and redirect_uri should be the supported and everything else should be dropped.
> 
> Discussion started about what "optional" means. Does the authorization server have to implement to implement even optional components?
> 
> John says that we need a new feature for adding and removing a new endpoint. This is a common use case and we don't want to revoke all the permissions when we do so.
> 
> Mike says that there is some additional material needed beyond client_id and redirect_uri.
> John agrees.
> 
> Prateek says that we need to identify a minimal subset and have extensions defined.
> 
> Hannes will talk to Derek about the next steps. Expect another conference call soon.
>

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 27 Aug 2013 13:51:12 +0100

anyone :) ?

Begin forwarded message:

From: Antonio Sanso <[email-masked]<mailto:[email-masked]>>
Date: August 23, 2013 6:42:18 PM GMT+02:00
To: John Bradley <[email-masked]<mailto:[email-masked]>>
Cc: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]> WG" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OAUTH-WG] Dynamic Client Registration Conference Call - Meeting Minutes (22. Aug)

regards

Antonio

Cc: Hannes Tschofenig; [email-masked]<mailto:[email-masked]> WG

John B.

On 2013-08-23, at 4:55 AM, Antonio Sanso <[email-masked]<mailto:[email-masked]>> wrote:

Hi Hannes,

Just my 0.02 $

Thanks and regards

Antonio

---- Meeting Minutes ----

Participants:
- William Kim
- John Bradley
- Antonio Sanso
- Mike Jones
- Phil Hunt
- Justin Richer
- Hannes Tschofenig
- Derek Atkins
- Amanda Anganes
- Morteza Ansari
- Brian Campbell
- Thomas Hardjono
- Prateek Mishra
- George Fletcher
- Tony Nadalin

Minutes

_______________________________________________
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