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.
Am 18.04.2012 21:51, schrieb Eran Hammer:
Because it is in the draft the WG is suppose to consider. It's a stated
dependency.
EH
-----Original Message-----
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, April 18, 2012 12:50 PM
To: Eran Hammer
Cc: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Dynamic Client Registration
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.
Am 15.04.2012 22:36, schrieb Eran Hammer:
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
-----Original Message-----
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Sunday, April 15, 2012 9:01 AM
To: Eran Hammer
Cc: Hannes Tschofenig; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Dynamic Client Registration
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.
On Apr 15, 2012, at 9:14 AM, Eran Hammer wrote:
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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Hannes Tschofenig
Sent: Friday, April 13, 2012 7:36 AM
To: oauth@ietf.org 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.
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
