[Openid-specs-ab] Fields that the server has provisioned on the client's behalf

Justin Richer jricher at mitre.org
Wed Feb 6 21:51:18 UTC 2013


Not quite: (2) can't end up in an inconsistent state because it's up to 
the server to enforce the cross-compatibility between the parameters. If 
the client changes "bar" but the server won't allow it because of the 
state of "baz", the server will put the kibosh on this and simply return 
to the client the new whole data model in which "bar" didn't actually 
successfully change. Or, if the server wants to, it can send back an 
invalid_client_metadata error response if it wants the client to be able 
to do something about it. Either way, the client won't have an 
inconsistent view of the world.

The inconsistency that you mention could occur in (1) where the client 
doesn't pay attention to the value of the field "bar" that comes back 
from the server so it never updates it. But since the client is 
operating in a fire-and-forget mode (whether it realizes it or not), it 
won't care.

  -- Justin


On 02/06/2013 04:42 PM, Mike Jones wrote:
>
> The problem with (2) is that if the returned values contain bar and 
> baz and the client changes bar without understanding its relationship 
> to baz (perhaps because baz isn't defined by OpenID Connect) and sends 
> the changed bar and the old baz in an update request, then you get to 
> an inconsistent state. Model (1) is fine, because the client is only 
> sending parameters that it understands.  I believe that clients should 
> be discouraged/prohibited from sending parameters that it doesn't 
> understand, even if they were returned to it by the registration 
> response, for the reasons above.
>
> -- Mike
>
> *From:*Justin Richer [mailto:jricher at mitre.org]
> *Sent:* Wednesday, February 06, 2013 1:33 PM
> *To:* Mike Jones
> *Cc:* John Bradley; Brian Campbell; openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Fields that the server has 
> provisioned on the client's behalf
>
> I agree with John's reading of it. I think it's just cleaner that if 
> the client doesn't send a field, then the server shouldn't change it.
>
> I really disagree with the notion of going back to the old way of the 
> registration not returning the client information, especially if OIDC 
> doesn't adopt the "client configuration read" parameter. Hiding from 
> server-asserted parameters doesn't really change the problem. The 
> client would still send {foo: A, bar: B} to the server and we'd be in 
> the exact same predicament that I outline below. Except now, the 
> client has *no chance* to do something sensible and send all fields.
>
> We can work around this by being very, very specific about what the 
> *server* does with updates from the client. The current text that 
> implies a full replace of all fields, whether they're present or not, 
> is insufficient. This, you'll note, is the nature of my suggested 
> change to the update semantics -- text that makes it explicit what the 
> server is supposed to do when fields are present, missing, or null. 
> The fact that it happens to allow for a partial-update is a side effect.
>
> In reality, I believe most clients will do one of two things with 
> updating their info, no matter what the servers/specs:
>
> 1) Keep a data model object around of their known fields and push 
> those to the server every time. They'll largely ignore what comes back 
> from the server except for the fields that are solely the purview of 
> the server to assert: client_id, client_secret, 
> registration_access_token, and the like. If there's a core OIDC field 
> like, say, default_acr that they don't care about, they'll never 
> notice or send it. When they want to update client_name, they'll drop 
> it into their model object that they used during registration and send 
> it to the update endpoint.
>
> 2) Download the data model from the server with all of the fields 
> filled in. Since it's a JSON object, they'll probably keep it around 
> as such. When they need to update a field, they'll push the update 
> into the right member, PUT the whole object up to the server, and 
> download the new version that comes back as a result.
>
> (Really, really smart clients will do #2 and then follow with an 
> integrity check on the values to make sure that they got what they 
> wanted.)
>
> I believe that both of these cases are better served by the semantics 
> that I have outlined for server action and that there are far too many 
> ambiguities of what constitutes proper server behavior with the 
> current language and semantics, as I read them at least.
>
> Finally, all of this came about when I sat down to actually try and 
> implement the old OIDC registration spec and realized that there 
> wasn't a clear answer as to what the server should do in these cases. 
> That's why I raised the issue in the first place and why I've 
> incorporated these semantics into the OAuth DynReg draft.
>
>  -- Justin
>
> On 02/06/2013 04:13 PM, Mike Jones wrote:
>
>     I think Justin allows returned fields with unknown meanings to be
>     sent back in an update request, and I would at least strongly
>     recommend against doing that.
>
>     I disagree with you that partial-replace is cleaner.  A whole
>     bunch of potential ambiguities that are being discussed in this
>     thread just won't come up if we maintain the current semantics
>     that update requests must contain a complete list of the intended
>     new parameter values.
>
>     In particular, if we imply or allow not-understood result
>     parameters to be passed back in as update parameters, we've opened
>     a Pandora's box of unexpected and non-interoperable behaviors.
>
>     I'm beginning to think that Client Register should only return the
>     registration_access_token, client_id, and client_secret, like it
>     used to.  Then these ambiguities won't be able to arise.
>
>     -- Mike
>
>     *From:*John Bradley [mailto:ve7jtb at ve7jtb.com]
>     *Sent:* Wednesday, February 06, 2013 1:04 PM
>     *To:* Mike Jones
>     *Cc:* Justin Richer; Brian Campbell;
>     openid-specs-ab at lists.openid.net
>     <mailto:openid-specs-ab at lists.openid.net>
>     *Subject:* Re: [Openid-specs-ab] Fields that the server has
>     provisioned on the client's behalf
>
>     Yes,  I think that is how Justin currently has it.
>
>     Elements not sent in the request are not changed.    That is
>     different from our prior strategy of replacing the entire config,
>     but I think cleaner.
>
>     John B.
>
>     On 2013-02-06, at 1:54 PM, Mike Jones <Michael.Jones at microsoft.com
>     <mailto:Michael.Jones at microsoft.com>> wrote:
>
>
>
>
>     I think the cleanest thing to do is to recommend that clients NOT
>     send back of the fields returned from the registration request,
>     other than registration_access_token and client_id in update
>     requests.  That way the ambiguities and potential inconsistencies
>     that could arise from a client changing "bar" but not "baz"
>     because it doesn't know what "baz" means, but the new "bar" and
>     "baz" values being incompatible can't arise.
>
>     The client should treat most of the information returned from the
>     registration as informational -- not actionable -- especially any
>     fields whose meanings aren't defined by OpenID Connect.
>
>     -- Mike
>
>     *From:*Justin Richer [mailto:jricher at mitre.org <http://mitre.org>]
>     *Sent:*Wednesday, February 06, 2013 11:41 AM
>     *To:*Brian Campbell
>     *Cc:*Mike Jones; openid-specs-ab at lists.openid.net
>     <mailto:openid-specs-ab at lists.openid.net>
>     *Subject:*Re: [Openid-specs-ab] Fields that the server has
>     provisioned on the client's behalf
>
>     So the problem comes if you have a "full replace" semantic for the
>     update. Say a client knows about:
>
>     { foo: "A",  bar: "B" }
>
>     And it sends those in a registration request. The server sends back:
>
>     { client_id: "aksdfjhasd", foo: "A", bar: "OTHER", baz: "C" }
>
>     The question is, do we require the client to send back the entire
>     object above each time, or can it simply send back the original {
>     foo: "A", bar "B" } request? If it does the latter, what is the
>     server supposed to do? Does it delete the "baz: C" mapping? Does
>     it try to replace the "bar: OTHER" with "bar: B"?
>
>      -- Justin
>
>
>
>     On 02/06/2013 02:37 PM, Brian Campbell wrote:
>
>         I'm confused. Especially about a client providing something in
>         a response.
>
>         That aside, I think I get your intent but wasn't sure what was
>         expected with default values that aren't really/necessarily
>         "provisioned" and may not even ever be used. Or if it matters.
>
>         On Wed, Feb 6, 2013 at 8:08 AM, Justin Richer
>         <jricher at mitre.org <mailto:jricher at mitre.org>> wrote:
>
>         Since I have been arguing for a safer update mechanic, the
>         intent was actually:
>
>         5) The client may provide these values in its update response,
>         either changed or as-given from the server. If the client does
>         not provide these values, the server isn't supposed to change
>         them. The server is free to reject any requested changes to
>         any field from the client, but MUST send back the current and
>         correct value to the client.
>
>         With the current language of replace-all, this turns into:
>
>         6) The client must provide all values in its update response,
>         and the server is free to reject and replace any values for
>         any field but MUST send back the current and correct value to
>         the client.
>
>         The motivating factor for me is that, in our implementation at
>         least, there are a lot of fields that are either defaulted or
>         restricted by the server, or are defined outside of the base
>         OAuth/OIDC world that some of our clients care about (but
>         others safely ignore). So the client could be getting back a
>         picture of itself that's not quite what it asked for in the
>         first place, and it should be made aware of those bits and pieces.
>
>         It's all about the client getting a *complete* and *accurate*
>         model of itself if it wants one.
>
>          -- Justin
>
>
>
>
>
>
>         On 02/06/2013 01:37 AM, Mike Jones wrote:
>
>             Hi Justin,
>
>             In his review comments, Brian wrote:
>
>             http://openid.net/specs/openid-connect-registration-1_0-14.html#ClientRegisterResponse
>             2.2.1.  Client Register Operation Response
>
>             This section and 2.2.3 have "Additionally, the server MUST
>             include all registered metadata about a client as
>             described inSection 2.1
>             <http://openid.net/specs/openid-connect-registration-1_0-14.html#ClientRegistration>,
>             including any fields that the server has provisioned on
>             the client's behalf." What is the expected behavior for
>             default values from 2.1 (that very well might not be
>             stored anywhere).
>
>             Justin, can you answer Brian's question about the intent
>             of the text about "fields that the server has provisioned
>             on the client's behalf"?  He seems to be raising a point
>             of ambiguity in the registration spec as currently worded.
>
>             One aspect of this is whether in an update operation:
>
>             (1) the client should be expected to be able to provide
>             new values for these fields that it didn't previously
>             request in its initial reservation request,
>
>             (2) the client should be prohibited from providing new
>             values for these fields that it didn't previously request
>             in its initial reservation request,
>
>             (3) it is unspecified whether the client can providing new
>             values for these fields that it didn't previously request
>             in its initial reservation request,
>
>             (4) whether the client must provide the same values for
>             these fields that it didn't previously request in its
>             initial reservation request.
>
>             I believe that if we're going to allow the registration
>             responses to contain the values of fields that were not in
>             the initial registration request and that are potentially
>             not specified in the OpenID Connect specifications, that
>             these questions need to be answered.
>
>             Thanks,
>
>             -- Mike
>
>
>         _______________________________________________
>         Openid-specs-ab mailing list
>         Openid-specs-ab at lists.openid.net
>         <mailto:Openid-specs-ab at lists.openid.net>
>         http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>     _______________________________________________
>     Openid-specs-ab mailing list
>     Openid-specs-ab at lists.openid.net
>     <mailto:Openid-specs-ab at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130206/c6646d25/attachment-0001.html>


More information about the Openid-specs-ab mailing list