Hi all,
based on a conversion with one of our developers I would prefer the DynReg
style.
regards,
Torsten.
Am 09.01.2013 um 21:05 schrieb "Richer, Justin P." <jric...@mitre.org>:
> It's been a few days now and I haven't seen any traffic from the group about
> this at all, so I'll just come out and ask for opinions. The two proposals
> are:
>
> OIDC-style:
> - inclusion of field replaces that field value on the server with the new
> value
> - omission of field deletes that field value on the server
>
> DynReg style:
> - inclusion of field replaces that field value on the server with the new
> value
> - omission of field tells the server to leave its current value alone
> - inclusion of field with an empty string value deletes/clears that field
> value from the server
>
>
> Should the OAuth2 Dyn Reg spec adopt the OIDC semantics, or keep its current
> semantics? Why? Is there another option that's even better?
>
> -- Justin
>
>
> On Jan 5, 2013, at 2:36 PM, "Richer, Justin P." <jric...@mitre.org> wrote:
>
>> 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: oauth-boun...@ietf.org [oauth-boun...@ietf.org] on behalf of John
>> Bradley [ve7...@ve7jtb.com]
>> Sent: Friday, January 04, 2013 7:13 PM
>> To: Mike Jones
>> Cc: oauth@ietf.org
>> 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 <michael.jo...@microsoft.com> 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
>>> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
