Mike, John, thanks for the feedback. I hope and anticipate that this
conversation will help improve both drafts.
I disagree with the assessment here that it makes things more complicated in
the simple case. How? The way that DynReg is currently written, if the client
simply POSTs back the entire set of information that it has about itself every
time, which I anticipate the most simple clients will do, then it still behaves
as expected. Doesn't it? There's nothing in the draft that REQUIRES an
incomplete POST, it just ALLOWS it to happen and defines what to do when it
does. Furthermore, it makes it *safer* if the client POSTs something that is
incomplete from the *server's* perspective, since the semantics are now,
explicitly, to leave alone any values that are left out. In other words, it's
my view that this actually makes things far simpler for clients wanting to do
simple things, and makes more complex things possible. This is especially in
light of the requirement of the server to echo out the actual full state of the
client during the transaction. Having implemented this myself, it's really not
very complex from either side. The server is marginally more complex, but it
leaves fewer cases undefined or "up to the server to decide".
Part of the motivation I had for changing this here was to cope with the cases
where the server asserts things about the client that the client doesn't
register about itself in the first place, and I wanted something that was
simple and programmatic to implement from both sides. In other words, it's
assuming that the *server* has the most complete picture of the client's state,
not the *client*, which is the assumption made in OIDC and by Mike and John's
comments below. Let's take this example as a concrete case (formatting and
parameter names are notional and might be off, I'm typing from memory):
Client registers with params:
client_name=Foo
token_endpoint_auth_type=client_secret_basic
Server sends back to the client:
{
client_name: Foo
client_secret: super-secret-secret
token_endpoint_auth_type: client_secret_basic
scope: read open dennis
registration_access_token: TOKEN
}
So the client never asked for scope restriction, but the server decided
(however it wanted to, probably by a defaulting mechanism) to give the client
three scopes. In the current OIDC spec, the client would never even know this
happened because this information isn't ever echoed back (though this at least
is changing). Even if it did know about this parameter, it didn't ask for
anything in particular in that field, so it now has to keep around something
that it doesn't really know what to do with. So with that in mind, the client
decides to change its name and sends back all the parameters that it knows
about:
client_name=Bar
token_endpoint_auth_type=client_secret_basic
access_token=TOKEN
Now in the OIDC definition of the semantics, this tells the server to clear out
the existing "scope" value, because it's not included in the request. But the
server really shouldn't do that, should it? You could argue that because it's a
server-defaulted parameter and that the server should know to treat it special.
But then the server would have to track which fields are still in a "defaulted"
state, or keep some kind of programming logic that says "a blank on an update
actually means something else". Which fields does this apply to? Neither of
those are "simple".
In the current definition of the DynReg spec, the client not only knows the
fields and can do something about them if it wants to, it can also *safely*
ignore them in responses. If the client sends back the same set above, dealing
only in the parameters that it knows and cares about, the server now has an
unambiguous message when the client omits the "scope" field.
With this behavior, though, we do need the equivalent of "set to null" in order
to explicitly empty out the value of an existing field. I took the approach of
using a blank value -- expressed in HTTP forms as an empty string. I'm open to
other suggestions if there's a better/cleaner approach to this part of it, but
this was the best I could come up with.
Finally, it's not a bandwidth issue at all, so let's just ignore that
particular red herring. :)
-- Justin
________________________________
From: [email protected] [[email protected]] on behalf of John Bradley
[[email protected]]
Sent: Friday, January 04, 2013 7:13 PM
To: Mike Jones
Cc: [email protected]
Subject: Re: [OAUTH-WG] Difference between client_update semantics in
draft-ietf-oauth-dyn-reg and OpenID Connect Registration
We did discuss this issue in the connect WG.
The decision was made to always completely replace. That prevents unknown
states if a update fails.
I think the always replace everything rule is simpler, though admittedly more
bandwidth is required. However bandwidth is not a significant factor for this
as far as I know.
John B.
On 2013-01-04, at 8:55 PM, Mike Jones
<[email protected]<mailto:[email protected]>> wrote:
The client_update operation in
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03 does something different
than the operation upon which it was based
fromhttp://openid.net/specs/openid-connect-registration-1_0-13.html.
Specifically, while the OpenID Connect operation replaces all field values, the
OAuth operation allows only selective fields to be replaced, designating fields
to remain unchanged by specifying their value as the empty string (“”).
I'm personally not happy with the change to the semantics of client field
inclusion. Updating some but not all fields is a substantially more
complicated operation than replacing all fields. Is there some use case that
motivates this? I don't think it's a substantial burden on the registering
party to remember all the field values from the initial registration and then
selectively use them for update operations, when needed. Then the work goes to
the (I suspect rare) parties that need partial update - not to every server.
It complicates the simple case, rather than pushing the complexity to the rare
case, violating the design principle “make simple things simple and make more
complicated things possible”.
Is anyone opposed to updating the OAuth Registration semantics to match the
Connect registration semantics? Is so, why?
Thanks,
-- Mike
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
