Subject: [OAUTH-WG] Dynamic Client Registration

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Apr 2012 17:36:02 +0300

Hi all, 

at the IETF#83 OAuth working group meeting we had some confusion about the Dynamic Client Registration and the Simple Web Discovery item. I just listened to the audio recording again. 

With the ongoing mailing list discussion regarding WebFinger vs. Simple Web Discovery I hope that folks had a chance to look at the documents again and so the confusion of some got resolved.  

I believe the proposed new charter item is sufficiently clear with regard to the scope of the work. Right? 
Here is the item again:
"
Jul. 2013  Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard

[Starting point for the work will be 
http://tools.ietf.org/html/draft-hardjono-oauth-dynreg
] 
"

Of course there there is a relationship between Simple Web Discovery (or WebFinger) and the dynamic client registration since the client first needs to discover the client registration endpoint at the authorization server before interacting with it. 

Now, one thing that just came to my mind when looking again at draft-hardjono-oauth-dynreq was the following: Could the Client Registration Request and Response protocol exchange could become a profile of the SCIM protocol? In some sense this exchange is nothing else than provisioning an account at the Authorization Server (along with some meta-data).

Is this too far fetched? 

Ciao
Hannes

---

From: Eve Maler <[email-masked]>
Date: Fri, 13 Apr 2012 18:29:26 -0700

Hi Hannes-- That's kind of a cool idea. You're right that it's a "client account" of sorts. At least worth exploring, I'd say, unless a SCIM expert pipes up with a reason why not.

	Eve

On 13 Apr 2012, at 7:36 AM, Hannes Tschofenig wrote:

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

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

---

From: William Mills <[email-masked]>
Date: Sat, 14 Apr 2012 09:01:05 -0700 (PDT)

Yeah, SCIM as a way to federate and distribute info like this seems sane, with extensions for the data items we need here.  The hard part is still around the security stuff which they have not dealt with yet, and that's going to be a blocker until it's solved.  Authority to update elemnts or namespaces is going to be needed, and that's a hard problem.

-bill

>________________________________
> From: Eve Maler <[email-masked]>
>To: Hannes Tschofenig <[email-masked]> 
>Cc: "[email-masked] WG" <[email-masked]> 
>Sent: Friday, April 13, 2012 6:29 PM
>Subject: Re: [OAUTH-WG] Dynamic Client Registration
>

---

From: Eran Hammer <[email-masked]>
Date: Sun, 15 Apr 2012 06:14:06 +0000

I'd like to see 'Dynamic Client Registration' removed from the charter along with SWD for the sole reason that figuring out a generic discovery mechanism is going to take some time and this WG has enough other work to focus on while that happens elsewhere. I expect this to come back in the next round with much more deployment experience and discovery clarity.

EH

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hannes Tschofenig
> Sent: Friday, April 13, 2012 7:36 AM
> To: [email-masked] WG
> Subject: [OAUTH-WG] Dynamic Client Registration
> 
> Hi all,
> 
> at the IETF#83 OAuth working group meeting we had some confusion about
> the Dynamic Client Registration and the Simple Web Discovery item. I just
> listened to the audio recording again.
> 
> With the ongoing mailing list discussion regarding WebFinger vs. Simple Web
> Discovery I hope that folks had a chance to look at the documents again and
> so the confusion of some got resolved.
> 
> Of course there there is a relationship between Simple Web Discovery (or
> WebFinger) and the dynamic client registration since the client first needs to
> discover the client registration endpoint at the authorization server before
> interacting with it.
> 
> Now, one thing that just came to my mind when looking again at draft-
> hardjono-oauth-dynreq was the following: Could the Client Registration
> Request and Response protocol exchange could become a profile of the
> SCIM protocol? In some sense this exchange is nothing else than provisioning
> an account at the Authorization Server (along with some meta-data).
> 
> Is this too far fetched?
> 
> Ciao
> Hannes
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Apr 2012 19:01:14 +0300

Hi Eran, 

you are saying that you are not interested in the dynamic client registration work and that's OK. There are, however, a couple of other folks in the group who had expressed interest to work on it, to review and to implement it. 

Note also that the discovery and the dynamic client registration is different from each other; there is a relationship but they are nevertheless different. 

Ciao
Hannes

PS: Moving the Simple Web Discovery to the Apps area working group does not mean that it will not be done. On the contrary there will be work happing and we are just trying to figure out what the difference between SWD and WebFinger is.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Apr 2012 19:06:00 +0300

Bill,

I actually do not think that the security of either SCIM or this work is particularly challenging. 

For SCIM I assume that there is a close relationship between the SCIM client and a SCIM server (as it is common in an enterprise or single administrative domain scenario). 

For the dynamic registration I assume that there is no relationship between the two in the worst case and therefore this turns into a leap of faith type of provisioning. 

I may be completely wrong here but that's the impression I have at the moment. 

In any case, these questions are something to deal with once we have started the work. At the moment we are still attempting to finalize the re-chartering. 

Ciao
Hannes

---

From: Eran Hammer <[email-masked]>
Date: Sun, 15 Apr 2012 20:36:01 +0000

Where did I say I'm not interested in this work?!

All I was saying is that it would be better to postpone it until the discovery layer, which this draft clearly relies upon, is a bit clearer. I would be satisfied with a simple note stating that if the discovery work at the APP area isn't complete, the WG may choose to delay work on this document until ready.

EH

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Sunday, April 15, 2012 9:01 AM
> To: Eran Hammer
> Cc: Hannes Tschofenig; [email-masked] WG
> you are saying that you are not interested in the dynamic client registration
> work and that's OK. There are, however, a couple of other folks in the group
> who had expressed interest to work on it, to review and to implement it.
> 
> Note also that the discovery and the dynamic client registration is different
> from each other; there is a relationship but they are nevertheless different.
> 
> Ciao
> Hannes
> 
> PS: Moving the Simple Web Discovery to the Apps area working group does
> not mean that it will not be done. On the contrary there will be work happing
> and we are just trying to figure out what the difference between SWD and
> WebFinger is.
> 
> > I'd like to see 'Dynamic Client Registration' removed from the charter along
> with SWD for the sole reason that figuring out a generic discovery mechanism
> is going to take some time and this WG has enough other work to focus on
> while that happens elsewhere. I expect this to come back in the next round
> with much more deployment experience and discovery clarity.
> >
> > EH
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Hannes Tschofenig
> >> at the IETF#83 OAuth working group meeting we had some confusion
> >> about the Dynamic Client Registration and the Simple Web Discovery
> >> item. I just listened to the audio recording again.
> >>
> >> With the ongoing mailing list discussion regarding WebFinger vs.
> >> Simple Web Discovery I hope that folks had a chance to look at the
> >> documents again and so the confusion of some got resolved.
> >>
> >> Jul. 2013  Submit 'OAuth Dynamic Client Registration Protocol' to the
> >> IESG for consideration as a Proposed Standard
> >>
> >> WebFinger) and the dynamic client registration since the client first
> >> needs to discover the client registration endpoint at the
> >> authorization server before interacting with it.
> >>
> >> hardjono-oauth-dynreq was the following: Could the Client
> >> Registration Request and Response protocol exchange could become a
> >> profile of the SCIM protocol? In some sense this exchange is nothing
> >> else than provisioning an account at the Authorization Server (along with
> some meta-data).
> >>
> >> Is this too far fetched?
> >>
> >> Ciao
> >> Hannes
> >>

---

From: Derek Atkins <[email-masked]>
Date: Mon, 16 Apr 2012 15:16:37 -0400

Eran Hammer <[email-masked]> writes:

> All I was saying is that it would be better to postpone it until the
> discovery layer, which this draft clearly relies upon, is a bit
> clearer. I would be satisfied with a simple note stating that if the
> discovery work at the APP area isn't complete, the WG may choose to
> delay work on this document until ready.

I don't feel that this is explicitly required, but I have no objection
to making it clearer in the charter that the DCR is dependent on
Discovery.  Hannes?

> EH

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 18 Apr 2012 21:49:34 +0200

Hi Eran,

why do you see a relationship between dynamic client registration and 
discovery? Basically, we don't care so far how a client finds tokens and 
end-user authorization point. Why is this any different for the client 
registration endpoint (or the revocation endpoint)? Or do you have a 
bigger picture in mind?

regards,
Torsten.

---

From: Eran Hammer <[email-masked]>
Date: Wed, 18 Apr 2012 19:51:11 +0000

Because it is in the draft the WG is suppose to consider. It's a stated dependency.

EH

> From: Torsten Lodderstedt [mailto:[email-masked]]
> Sent: Wednesday, April 18, 2012 12:50 PM
> To: Eran Hammer
> discovery? Basically, we don't care so far how a client finds tokens and end-
> user authorization point. Why is this any different for the client registration
> endpoint (or the revocation endpoint)? Or do you have a bigger picture in
> mind?
> 
> regards,
> Torsten.
> 
> > All I was saying is that it would be better to postpone it until the discovery
> layer, which this draft clearly relies upon, is a bit clearer. I would be satisfied
> with a simple note stating that if the discovery work at the APP area isn't
> complete, the WG may choose to delay work on this document until ready.
> >
> > EH
> >
> >> you are saying that you are not interested in the dynamic client
> >> registration work and that's OK. There are, however, a couple of
> >> other folks in the group who had expressed interest to work on it, to
> review and to implement it.
> >>
> >> Note also that the discovery and the dynamic client registration is
> >> different from each other; there is a relationship but they are
> nevertheless different.
> >>
> >> Ciao
> >> Hannes
> >>
> >> PS: Moving the Simple Web Discovery to the Apps area working group
> >> does not mean that it will not be done. On the contrary there will be
> >> work happing and we are just trying to figure out what the difference
> >> between SWD and WebFinger is.
> >>
> >> with SWD for the sole reason that figuring out a generic discovery
> >> mechanism is going to take some time and this WG has enough other
> >> work to focus on while that happens elsewhere. I expect this to come
> >> back in the next round with much more deployment experience and
> discovery clarity.
> >>> EH
> >>>
> >>>> Jul. 2013  Submit 'OAuth Dynamic Client Registration Protocol' to
> >>>> the IESG for consideration as a Proposed Standard
> >>>>
> >>>> WebFinger) and the dynamic client registration since the client
> >>>> first needs to discover the client registration endpoint at the
> >>>> Now, one thing that just came to my mind when looking again at
> >>>> draft- hardjono-oauth-dynreq was the following: Could the Client
> >>>> profile of the SCIM protocol? In some sense this exchange is
> >>>> nothing else than provisioning an account at the Authorization
> >>>> Server (along with
> >> some meta-data).
> >>>> Is this too far fetched?
> >>>>
> >>>> Ciao
> >>>> Hannes
> >>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 18 Apr 2012 21:56:51 +0200

Hi Eran,

thanks for pointing this out. I took a quick look on the document. Seems 
the I-D combines registration and discovery. I think both should be kept 
separat. So I would suggest to remove section 5 and the dependency is gone.

regards,
Torsten.

---

From: Justin Richer <[email-masked]>
Date: Wed, 18 Apr 2012 16:00:04 -0400

So it's a "known issue". I think that's an artificial reason to leave it 
and a reasonable section to be cut out first.

  -- Justin

---

From: Eran Hammer <[email-masked]>
Date: Wed, 18 Apr 2012 20:02:16 +0000

WFM. An updated I-D without it would be great.

EH

> Sent: Wednesday, April 18, 2012 12:57 PM
> To: Eran Hammer
> thanks for pointing this out. I took a quick look on the document. Seems the
> I-D combines registration and discovery. I think both should be kept separat.
> So I would suggest to remove section 5 and the dependency is gone.
> 
> regards,
> Torsten.
> 
> >> discovery? Basically, we don't care so far how a client finds tokens
> >> and end- user authorization point. Why is this any different for the
> >> client registration endpoint (or the revocation endpoint)? Or do you
> >> have a bigger picture in mind?
> >>
> >> regards,
> >> Torsten.
> >>
> >>> discovery
> >> layer, which this draft clearly relies upon, is a bit clearer. I
> >> would be satisfied with a simple note stating that if the discovery
> >> work at the APP area isn't complete, the WG may choose to delay work
> on this document until ready.
> >>> EH
> >>>
> >>>> does not mean that it will not be done. On the contrary there will
> >>>> be work happing and we are just trying to figure out what the
> >>>> difference between SWD and WebFinger is.
> >>>>
> >>>> work to focus on while that happens elsewhere. I expect this to
> >>>> come back in the next round with much more deployment experience
> >>>> and
> >> discovery clarity.
> >>>>> EH
> >>>>>
> >>>>>> about the Dynamic Client Registration and the Simple Web
> >>>>>> Discovery item. I just listened to the audio recording again.
> >>>>>>
> >>>>>> Simple Web Discovery I hope that folks had a chance to look at
> >>>>>> the documents again and so the confusion of some got resolved.
> >>>>>>
> >>>>>> I believe the proposed new charter item is sufficiently clear
> >>>>>> with regard to the scope of the work. Right?
> >>>>>> Here is the item again:
> >>>>>> "
> >>>>>> Registration Request and Response protocol exchange could
> become
> >>>>>> a profile of the SCIM protocol? In some sense this exchange is

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 18 Apr 2012 16:17:02 -0400

+1 for keeping registration and discovery separate.

(As is typical, Torsten had beaten me to saying just what I was thinking 
about and preparing to to say.  The only consolation is that he 
expressed it better than I would have.)

Igor

On 4/18/2012 3:56 PM, Torsten Lodderstedt wrote:
> Hi Eran,
>
> thanks for pointing this out. I took a quick look on the document. 
> Seems the I-D combines registration and discovery. I think both should 
> be kept separat. So I would suggest to remove section 5 and the 
> dependency is gone.
>
> regards,
> Torsten.
>
>>> and end-
>>> would be satisfied