Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-dyn-reg-management-05

John Bradley <ve7jtb@ve7jtb.com> Mon, 01 December 2014 15:23 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3C01A1EFE for <oauth@ietfa.amsl.com>; Mon, 1 Dec 2014 07:23:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5jMGb3mcS89 for <oauth@ietfa.amsl.com>; Mon, 1 Dec 2014 07:23:28 -0800 (PST)
Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59AFA1A6EE5 for <oauth@ietf.org>; Mon, 1 Dec 2014 07:22:26 -0800 (PST)
Received: by mail-wg0-f54.google.com with SMTP id l2so14431692wgh.13 for <oauth@ietf.org>; Mon, 01 Dec 2014 07:22:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=XtA+UVhce/pDDgfW1NOw4w8exTDnsI6ZZz2UiK2eMoM=; b=MJdnKs5H11cuXCbl2fXd5QyKODmyd54n1UoVyjkY2CgQmJz6e35jsnf60w1HjEI7Gf /BlAZ7X6N68Eyz0BqXPzQarq6xkBG8fR1MVQcLTYg6DLRx6M5i7iJXr6DWI5sBXuuEtA WhRsah+13x2imjG1SrdoZ4UAiAVOIk5sgNTJSuyAa7YVvvu5UK7ycQlzMjs2TLTe21Tc jGoY50QM08a0LEFpOJ/ywDK8HWAV07jiYjjtThgXIdpGJHdKvIbbJWmqWkj6iZTCdAyV sRoqLM52t4tv2O99Fe+xzIMqmeJXVku7k1OU+y6OeRGVU93+v9iQHxYg4keGl+Chv2kQ L4Ig==
X-Gm-Message-State: ALoCoQl3SEYOxdd1fiyK6w7+aPCirf6tecqUWvzsClrpbxzKlBPyYfS5pFqrvp7cA49f81baBTuv
X-Received: by 10.194.133.66 with SMTP id pa2mr50022866wjb.134.1417447343944; Mon, 01 Dec 2014 07:22:23 -0800 (PST)
Received: from [10.47.81.161] (host217-39-14-209.in-addr.btopenworld.com. [217.39.14.209]) by mx.google.com with ESMTPSA id h14sm28852477wic.8.2014.12.01.07.22.21 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Dec 2014 07:22:22 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_98FCB04A-84D0-40A9-9244-30444CAF3F63"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <547C7C88.1010000@gmx.net>
Date: Mon, 01 Dec 2014 12:21:03 -0300
Message-Id: <99059A3E-9D42-45FB-8DF9-3C33022F92C9@ve7jtb.com>
References: <54739067.3020602@gmx.net> <8C669C03-CF70-445C-9FA7-280DE94084A2@mitre.org> <547582B8.5000509@gmx.net> <7A200D67-0D5E-4B71-A810-D456B6FDC332@mit.edu> <4724812B-DA0A-4905-8B2D-E5FC1722DC63@mit.edu> <547C347C.7070908@gmx.net> <7D2A7C57-3583-4025-86BA-83AAC6827CB3@ve7jtb.com> <547C7C88.1010000@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/BNEVZ_3QalBPbrFR0hcMuN2j6qg
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-dyn-reg-management-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Dec 2014 15:23:39 -0000

Inline
> On Dec 1, 2014, at 11:34 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
> 
> Hi John,
> 
> thanks for jumping in.
> 
> On 12/01/2014 01:18 PM, John Bradley wrote:
>> Hannes,
>> 
>> You seem not to like the idea of client credential rotation.
> 
> It is not that I do not like it but I would like to accomplish a few
> things with my shepherd review:
> 
> * Ensure that the document is consistent and that nothing is missing.
> * Double-check whether the design decisions have really been understood.
> * Avoid unnecessary complexity.
> * Document design decisions so that the reader also understands them
> rather than having to read through the mailing list achieve.
> 
> 
>> This is something we have wrestled with from the very beginning of
>> Connect Dynamic client registration. In the early drafts we re-used
>> the client secret for authentication to the registration/update
>> endpoint.
> 
> Actually, I would see the client secret and the credential rotation as
> two separate issues.
> 
They are unless you need the client secret to do the update.  If you do that causes problems with using the secret to update the secret.

>> 
>> That was rejected by developers as too likely to cause unrecoverable
>> errors if transactions fail. eg the server thinks it has rotated the
>> secret, but the client doesn't  correctly get the response. They also
>> found the dual use of client secret confusing.
> 
> It is always good to hear developer feedback. I guess that feedback was
> given in person rather than on the mailing list.
> 
That happened before the contribution Connect work as a IETF draft and is on the Connect mailing list.

> 
>> 
>> When we added OAuth protection to registration,  it made sense to use
>> the same mechanism to protect the endpoint for updates. This allowed
>> the client secret rotation to be recoverable if there was a problem.
> 
> It certainly makes sense to re-use mechanisms.
> 
>> 
>> Ultimately we didn't do updates for symmetric client secrets in the
>> Connect version, leaving that for the IETF draft.
> 
> Interesting. Do you expect to later inherit the work back to the OpenID
> Connect?

If there is a RFC that Connect can reference and profile to add the additional
configuration attributes that Connect registration has then that would be a good outcome in my 
opinion.   I don't think we have ever intended to have two incomparable registration specs.
> 
>> 
>> Via registration of a jwks_uri in Dynamic Client registation, server
>> based clients can rotate asymmetric keys. However that doesn't  help
>> native clients at all, given that they can't publish a jwks_uri
>> without some other protocol and credentials to push it to a server
>> (Turtles).
>> 
>> You ask why have the complexity of key rollover when the client can
>> just re-register (start the protocol flow from the start)
>> 
>> The answer to that is that many AS use sticky scopes.  If a client_id
>> is granted scope "x" by a user then the user is not re-prompted to
>> authorize scope "x"  again for that client if the client asks for
>> scopes "x" and "y" on a later request.   When the client's
>> access/refresh tokens expire and the user is sent back to the AS for
>> a new code the AS wants to reduce the complexity of the dialogs. 
>> (Privacy people may argue that people should be re-prompted every
>> time but that is not the current practice)
> 
> I am not sure whether this has anything to do with the dynamic client
> registration management API.
> 
> I was not under the assumption that the user would be asked to approve
> interactions with the dynamic client registration management API.

The user is not involved in consenting to the registration.

However if you create a new client_id to rotate the key the user must re do all the consents
that they had previously granted as it is a new client from the perspective of the AS.

So in that solution to key rollover you do ultimately involve the user, 
something that we are trying to avoid.

> 
>> 
>> If the client must get a new client_id every time it rotates it's
>> secret, then all of the previous grants are going to get blown away,
>> and it would need to invalidate all it's refresh tokens and start
>> again re authorizing every user.   That is such a scary idea to
>> clients that they would just never volunteer to rotate credentials,
>> servers would also probably never enforce rotation as well as this
>> would be seen as breaking OAuth.
> 
> I had naively thought that a new protocol run with the dynamic client
> registration protocol would not lead to a new client id when the client
> already has one.
> 
> It turns out, after re-reading the dynamic client registration protocol
> document, that the Client Registration Request does not offer a way for
> the client to transmit a previously obtained client id to the AS.
> Hence, the AS allocates a new client id (and a new client secret) unless
> it has some other unspecified ways to find out whether this is an
> already registered client or not.
> 
> Because of the way how the dynamic client registration protocol is
> written requires you to introduce another credential, the registration
> access token.

I think one thing that may be confusing people is that we are trying to use REST (irony).

Originally updates happened at the registration endpoint using the registration access token 
instead of the initial access token.  Effectively doing what you are thinking.

That is still possible if the registration_client_uri returned is the same URI at was used to register.

To be REST we create a new resource when a client_id is created and perform the update operations on it,
but it is up to the AS how to implement that. 

I suspect the only real difference is that we are using PUT as it is an existing resource rather than POST.


>> Clients needing to have two client_id and secrets to avoid blowing
>> away refresh tokens also adds a lot of complexity to clients and
>> would require a total rewrite.
> I agree that having two client ids and requesting a new client id with
> every new protocol run would be far from ideal.
> 
>> 
>> We could somehow migrate grants and refresh tokens over to a new
>> client_id and secret,  however this also seems more complicated for
>> both the client and AS, not really achieving anything more than
>> rotating the secret alone.
> 
> Sounds certainly complex.
> 
>> 
>> So that leaves us with the question of is it necessary to rotate
>> symmetric client secrets in the first place?
>> 
>> When HTTP basic is used for client authentication the client_secret
>> is a password that is passed in effectively plain text as part of the
>> request.
>> 
>> There are two issues to consider:
>> 
>> 1. Brute force attacks,  this can be mitigated by using high entropy
>> passwords (eg 256 bit) however RFC 6749 doesn't  provide any guidance
>> on that point. (I suspect most people based on the examples are using
>> 60-70 bits of entropy)  For low entropy passwords rotation is
>> required(especially since rate limiting may be difficult, yes I do
>> have an attack in mind)
> 
> We should have given recommendations for the use of the client secret.
> Our fault. But in any case, we are talking about an online attack here
> and doing a brute force attack on a server for the client secret might
> not necessarily be an efficient way to get anywhere.

That depends on how short the secret is and if there is any rate limiting.

> 
>> 
>> 2. Man in the middle attacks.  SSL encryption is deprecated but I
>> suspect is going to take a while to be turned off on the server side.
>> Mobile clients could loose both there secret and refresh token due to
>> this attack, or other certificate/DNS attacks.   Rotation limits the
>> window that those credentials are good for.  (though in many cases
>> all the damage that could be done can be done in one go)
> 
> I don't think that any increase of the key length for the client secret
> will make any difference here since we are sending the secrets in clear
> over the TLS protected channel. If the TLS channel is compromised then
> the attacker will see the keys.

Yes
> 
>> While I would like to get rid of symmetric key rotation I don't think
>> we can given the current deployment landscape.
> 
> From the discussion I conclude that the credential rotation is needed
> (because of the way how the dynamic client registration is currently
> designed and we don't want to re-design it at this point in time).
> 
We were told to make registration crate only no updates.  We did that
This spec is how you update.  It is really the same endpoint if you want it to be
from an implementation point of view.

John B.

> What would be useful is
> * to explain some of that background in the credential rotation section,
> and
> * issue a new draft.
> 
> I could then go through the document again and see whether I can draw a
> state machine to make the interactions a bit clear.
> 
> Ciao
> Hannes
> 
>> 
>> John B.
>> 
>>> On Dec 1, 2014, at 6:27 AM, Hannes Tschofenig
>>> <hannes.tschofenig@gmx.net> wrote:
>>> 
>>> Hi Justin,
>>> 
>>> a few comments inline:
>>> 
>>> On 11/26/2014 02:32 PM, Justin Richer wrote:
>>>> And by “6790” below I obviously mean RFC6749.
>>>> 
>>>> (Note to self, don’t write working group emails this early in the
>>>> morning.)
>>>> 
>>>> — Justin
>>>> 
>>>> On Nov 26, 2014, at 8:31 AM, Justin Richer <jricher@MIT.EDU 
>>>> <mailto:jricher@MIT.EDU>> wrote:
>>>> 
>>>>> 
>>>>> On Nov 26, 2014, at 2:35 AM, Hannes Tschofenig 
>>>>> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>>
>>>>> wrote:
>>>>> 
>>>>>> Hi Justin,
>>>>>> 
>>>>>> thanks for your quick response. A few remarks below.
>>>>>> 
>>>>>> On 11/24/2014 10:11 PM, Richer, Justin P. wrote:
>>>>>>> Hannes, thank you for the review. Answers inline.
>>>>>>> 
>>>>>>> On Nov 24, 2014, at 3:09 PM, Hannes Tschofenig 
>>>>>>> <hannes.tschofenig@gmx.net
>>>>>>> <mailto:hannes.tschofenig@gmx.net>> wrote:
>>>>>>> 
>>>>>>>> Hi Justin, Mike, John, Maciej,
>>>>>>>> 
>>>>>>>> as part of my shepherd write-up I carefully read through 
>>>>>>>> draft-ietf-oauth-dyn-reg-management-05. Overall the
>>>>>>>> document is in good shape but I have a few minor
>>>>>>>> clarification questions that should be resolved before
>>>>>>>> the document goes to the IESG.
>>>>>>>> 
>>>>>>>> In Section 1.4. "Registration Tokens and Client
>>>>>>>> Credentials" you explain the different credential types
>>>>>>>> and I was wondering why you aren't issuing client_secrets
>>>>>>>> to all clients instead of introducing another credential,
>>>>>>>> the registration access token. While you try to explain
>>>>>>>> the reasons those appear somewhat constructed. For
>>>>>>>> example, you say that "not all types of clients have
>>>>>>>> client credentials" but you are the author of the
>>>>>>>> specification and you can essentially decide what to do.
>>>>>>>> The registration access token is essentially the same as
>>>>>>>> the client credential since it is "is uniquely bound to
>>>>>>>> the client identifier".
>>>>>>>> 
>>>>>>>> I believe we have discussed this issue in the past but I
>>>>>>>> don't remember what the reasoning was. Can you describe
>>>>>>>> what your design rational was (and add it to the
>>>>>>>> document)?
>>>>>>> 
>>>>>>> That's exactly the question this section is trying to
>>>>>>> answer, and if it can be made clearer then please suggest
>>>>>>> some text that will help that purpose. The rationale for
>>>>>>> the registration access token is very simple: we want to
>>>>>>> have a means to call the management endpoint in a protected
>>>>>>> manner, and treating the management endpoint as an OAuth 
>>>>>>> Protected Resource makes a lot of sense. RFC6750 gives us
>>>>>>> the means to make an authorized call to an API endpoint, so
>>>>>>> we're re-using that instead of trying to invent some other
>>>>>>> mechanism. Shouldn't we be helping the world get away from
>>>>>>> API passwords?
>>>>>>> 
>>>>>>> And it's very true that not every client is going to have a
>>>>>>> client secret to use at the token endpoint -- some will
>>>>>>> have no use of one (public and implicit clients) and some
>>>>>>> will be using TLS or asymmetric keys (JWT assertions, for
>>>>>>> instance) or other mechanisms to authenticate that don't
>>>>>>> involve the secret. Instead of forcing these clients to use
>>>>>>> a client secret for one new endpoint, or forcing that 
>>>>>>> endpoint to potentially support the infinite number of
>>>>>>> client authentication mechanisms, we decided to just use
>>>>>>> OAuth. These are OAuth clients, remember -- they will *all*
>>>>>>> have the ability to send OAuth tokens to a protected
>>>>>>> resource already built in.
>>>>>>> 
>>>>>> 
>>>>>> Here is the point I don't quite get: the registration access
>>>>>> token is essentially the same as a client secret. You as a
>>>>>> specification author essentially decides whether clients will
>>>>>> get a client secret or a registration access token. It is
>>>>>> under your control.
>>>>>> 
>>>>>> To be more specific, here is what you could have done:
>>>>>> 
>>>>>> C -> S: Client Registration Request C <- S: Client
>>>>>> Information Response (with new client secret)
>>>>>> 
>>>>>> C -> S: Read or Update Request (with client id/client
>>>>>> secret) C <- S: Client Information Response
>>>>>> 
>>>>>> Instead, you currently have this exchange:
>>>>>> 
>>>>>> C -> S: Client Registration Request C <- S: Client
>>>>>> Information Response (with new reg. access token)
>>>>>> 
>>>>>> C -> S: Read or Update Request (with client id + reg. access
>>>>>> token) C <- S: Client Information Response
>>>>>> 
>>>>>> Do you see the similarity that I see?
>>>>> 
>>>>> For clients that use a client secret to authenticate to the
>>>>> token endpoint, your point makes sense, but for clients who
>>>>> would not otherwise have a client secret, it doesn’t. You end
>>>>> up with a confusing state where you’re giving somebody a
>>>>> “client_secret” which is defined in 6790 to be used at the
>>>>> token endpoint but then telling them not to use it at the token
>>>>> endpoint (where they use something else or do’t use it at all)
>>>>> but to use it at this new endpoint instead. Can you see the
>>>>> confusion point here? I think it’s only going to get worse as
>>>>> we get more clients that use auth mechanisms that don’t depend
>>>>> on a shared secret (public key, TLS, etc.).
>>>>> 
>>>>> Instead we’re giving people an OAuth access token to access a 
>>>>> protected API, something that OAuth clients ought to know how
>>>>> to do anyway. This mechanism also gives us an opportunity to
>>>>> potentially use the new PoP tokens (once they’re actually
>>>>> defined) in place of the bearer credential that’s defined
>>>>> today.
>>>>> 
>>> 
>>> I believe I now understand your line of argument.
>>> 
>>> You are saying that re-using the client secret for this purpose
>>> will confuse developers since the client credential is used in
>>> other places as well.
>>> 
>>> So, the confusion could then be:
>>> 
>>> * Client starts the dynamic client registration exchange without a 
>>> client secret. * Later than that exchange he gets a client secret,
>>> which is supposed to be used for the dynamic client registration
>>> management only * A developer might think that he can now also use
>>> that client secret with anything else as well where a client secret
>>> can be used.
>>> 
>>> 
>>> The questions are now:
>>> 
>>> a) Is this potential confusion real or just imagined? b) Wouldn't
>>> this be desired behaviour to begin with?
>>> 
>>> If it is a real concern and if you don’t' want to have that
>>> behaviour then maybe you want to motivate the design decision in
>>> that direction in Section 1.4.
>>> 
>>> 
>>> 
>>>>>> 
>>>>>>>> 
>>>>>>>> In Section 1.4.1. "Credential Rotation" you write:
>>>>>>>> 
>>>>>>>> " The Authorization Server MAY rotate the client's
>>>>>>>> registration access token and/or client credentials (such
>>>>>>>> as a "client_secret") throughout the lifetime of the
>>>>>>>> client. "
>>>>>>>> 
>>>>>>>> You might want to add reasons why the authorization
>>>>>>>> server may want to take this step.
>>>>>>> 
>>>>>>> OK, but there's nothing normative here in my view. It's
>>>>>>> basically up to the auth server to say "well let's make a
>>>>>>> new credential". Can you suggest text that would clarify
>>>>>>> this?
>>>>>>> 
>>>>>> 
>>>>>> What about making the spec simpler by not allowing credential
>>>>>> rotation? Rekying is a useful concept under two
>>>>>> circumstances, namely * when they provide a performance
>>>>>> improvement (such as it is the case with session resumption
>>>>>> in TLS where you can do an abbreviated handshake without all
>>>>>> the heavy public key crypto) * when the entrophy of the key
>>>>>> is exhausted, which typically happens if you exceed a number
>>>>>> of data packets sent under a given key. Often this is tied to
>>>>>> the way how freshness is ensured and the need to avoid 
>>>>>> encrypting data with the same initialization vector/nonce
>>>>>> twice.
>>>>>> 
>>>>>> Neither of these two cases seem to apply here (IMHO).
>>>>> 
>>>>> 
>>>>> Rekeying the client is useful in a whole lot more cases than
>>>>> these two, and most of them boil down to “Something seems
>>>>> fishy”. I think if anything we need to eventually figure out
>>>>> how to do *more* secret rotation, including a proactive
>>>>> mechanism started by the client (as Brian has mentioned, among
>>>>> others).
>>>>> 
>>> 
>>> 
>>> The alternative to rekeying (or secret rotation) inside the
>>> dynamic client registration management protocol is to actually
>>> re-start the protocol run from scratch.
>>> 
>>> To me it is not obvious whether the added complexity for
>>> credential rotation is worth the effort given the alternative.
>>> 
>>> 
>>>>>> 
>>>>>> 
>>>>>>>> 
>>>>>>>> There are also a bit too many SHOULDs in the document.
>>>>>>>> Every time you write SHOULD you have to keep in mind to
>>>>>>>> tell the reader what happens in the other case. For
>>>>>>>> example, in Section Section 1.4.1 you write:
>>>>>>>> 
>>>>>>>> " The registration access token SHOULD be rotated only in
>>>>>>>> response to an update request to the client configuration
>>>>>>>> endpoint, at which point the new registration access
>>>>>>>> token is returned to the client and the old registration
>>>>>>>> access token SHOULD be discarded by both parties. "
>>>>>>>> 
>>>>>>>> Here the question arises whether you are using the SHOULD
>>>>>>>> to indicate that the authorization server does not always
>>>>>>>> need to rotate the registration access token and if he
>>>>>>>> does then is must only happen in response to an update
>>>>>>>> request or does it indicate that the authorization server
>>>>>>>> could also rotate it in response to other calls?
>>>>>>> 
>>>>>>> It's more that the server SHOULD NOT throw out a
>>>>>>> registration access token that a client still thinks is
>>>>>>> good without some way to communicate the new token to the
>>>>>>> client. Think of it this way, you've got the token, the
>>>>>>> server decides to chuck it on you -- what do you do? You
>>>>>>> can try calling your READ or UPDATE operations to get the
>>>>>>> new one but no dice, your token is bad. So what we're
>>>>>>> saying here is not to throw out the client's only means of
>>>>>>> finding out if its keys are good anymore.
>>>>>> 
>>>>>> I think I got confused with the description of the state
>>>>>> management (as described in the document). There is some
>>>>>> fuzziness.
>>>>>> 
>>>>>> Here I would prefer to have either no rekeying (which would
>>>>>> make the issue go away) or a very deterministic way of
>>>>>> rekeying.
>>>>>> 
>>>>>> I prefer the former.
>>>>> 
>>>>> I’m not a fan of enforcing permanent credentials on the world.
>>>>> And we have the same construct with refresh tokens today, for
>>>>> what it’s worth.
>>> 
>>> It is only permanent in the sense of a full dynamic client
>>> registration management protocol run.
>>> 
>>> 
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> Also, in the second line one would wonder why the old
>>>>>>>> registration access token isn't mandatorily discarded. If
>>>>>>>> there are good reasons, then tell the reader.
>>>>>>> 
>>>>>>> We've tried to put requirements on the server discarding
>>>>>>> tokens in the past, but there was significant pushback from
>>>>>>> providers who use non-revocable time-limited tokens. Maybe
>>>>>>> they won't be doing that here, for the reason above.
>>>>>> 
>>>>>> 
>>>>>> I wouldn't reflect that in the document. Of course, you can
>>>>>> never be sure that the implementation really discards any
>>>>>> state but for the purpose of the protocol state machine it is
>>>>>> gone.
>>>>>> 
>>>>>>> 
>>>>>>>> Furthermore, the text in Section 2.2 seems to contract
>>>>>>>> this statement: " If the authorization server includes a
>>>>>>>> new client secret and/or registration access token in its
>>>>>>>> response, the client MUST immediately discard its
>>>>>>>> previous client secret and/or registration access token.
>>>>>>>> "
>>>>>>> 
>>>>>>> This is a requirement on the client, not the server, so
>>>>>>> it's not bound by the token lifetime restrictions above.
>>>>>>> We're telling the client to stop using a secret or token
>>>>>>> after it's been given a new one, that's fine.
>>>>>> 
>>>>>> OK
>>>>>> 
>>>>>>> 
>>>>>>>> In Section 2.2 you write: " However, since read
>>>>>>>> operations are intended to be idempotent, the read
>>>>>>>> request itself SHOULD NOT cause changes to the client's
>>>>>>>> registered metadata values. "
>>>>>>>> 
>>>>>>>> I am wondering whether this SHOULD NOT statement adds a
>>>>>>>> lot of value since you allow the request to change
>>>>>>>> metadata values.
>>>>>>> 
>>>>>>> I think you're right, since the metadata values might have
>>>>>>> changed through outside forces since the client last read,
>>>>>>> and all the clients need to be able to deal with that. We
>>>>>>> can remove that line.
>>>>>> 
>>>>>> OK
>>>>>> 
>>>>>>> 
>>>>>>>> You also write the security consideration section: " the 
>>>>>>>> registration access token MAY be rotated when the
>>>>>>>> developer or client does a read or update operation on
>>>>>>>> the client's client configuration endpoint. "
>>>>>>>> 
>>>>>>>> This means that the content of the registration access
>>>>>>>> token may also change with a read operation.
>>>>>>> 
>>>>>>> That's correct.
>>>>>>> 
>>>>>>>> Terminology:
>>>>>>>> 
>>>>>>>> Sometimes you write "Client Information Response" and
>>>>>>>> sometimes "client information response" The same with
>>>>>>>> "Authorization Server" and "authorization server"
>>>>>>> 
>>>>>>> They're all supposed to be lower cased, as is the style in
>>>>>>> RFC6749. I tried to bump everything down in a previous edit
>>>>>>> but it looks like I missed some.
>>>>>>> 
>>>>>>>> Typo:
>>>>>>>> 
>>>>>>>> " Some values in the response, including the
>>>>>>>> "client_secret" and r"egistration_access_token", MAY be
>>>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ different from those in the
>>>>>>>> initial registration response. "
>>>>>>> 
>>>>>>> Thanks, noted!
>>>>>>> 
>>>>>>>> 
>>>>>>>> In Section 2.4 "Client Delete Request" you write:
>>>>>>>> 
>>>>>>>> " The authorization server SHOULD immediately invalidate
>>>>>>>> all existing authorization grants and currently-active
>>>>>>>> tokens associated with this client. "
>>>>>>>> 
>>>>>>>> Under what circumstances wouldn't the authorization
>>>>>>>> invalidate all grants and active tokens?
>>>>>>> 
>>>>>>> When it's using a non-revocable stateless token and it
>>>>>>> can't physically do that. Too bad 2119 doesn't have MUST IF
>>>>>>> POSSIBLE or equivalent.
>>>>>> 
>>>>>> Maybe it would be good to add this information.
>>>>>> 
>>>>>> It might also be worthwhile whether this notion of a
>>>>>> non-vocable stateless token actually exists in this context
>>>>>> since we are really talking about the same infrastructure
>>>>>> here. This registration management mechanism is really very
>>>>>> central to the authorization server (unlike some other access
>>>>>> token mechanisms where we talk about the resource server,
>>>>>> which may be in a different administrative domain even).
>>>>> 
>>>>> Why doesn’t the existing SHOULD cover this?
>>> 
>>> Because the should does not explain when to revoke the
>>> grants/tokens and when not to do it. You wrote it in this email (in
>>> context of these non-revocable tokens) but how should an
>>> implementer know when he reads through the draft?
>>> 
>>> The problem is really about assumptions being made that are not 
>>> explained further. For example, the assumption that there are
>>> tokens that are not revocable and the implications that result from
>>> those on the design of the protocol (potentially at multiple places
>>> in the document).
>>> 
>>> 
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>>> You might also want to say what tokens you are talking
>>>>>>>> about since there are at least the following tokens
>>>>>>>> around: - access tokens - refresh tokens - registration
>>>>>>>> access tokens - initial access token
>>>>>>> 
>>>>>>> OK, we can add that.
>>>>>>> 
>>>>>>>> 
>>>>>>>> " If the server does not support the delete method, the
>>>>>>>> server MUST respond with an HTTP 405 Not Supported. "
>>>>>>>> 
>>>>>>>> Why aren't you demanding that the server must support
>>>>>>>> this method? This would essentially mean that there would
>>>>>>>> be some cases where deregistration isn't possible. Of
>>>>>>>> course, there may be the question how important
>>>>>>>> deregistration actually is if the registration 
>>>>>>>> automatically expires.
>>>>>>> 
>>>>>>> Because delete is not always an easy operation to
>>>>>>> implement. The client should be able to call the endpoint
>>>>>>> with the DELETE verb and at least know if it's allowed to
>>>>>>> do that or not.
>>>>>> 
>>>>>> Hmmm. I didn't know that the delete method is difficult to
>>>>>> implement.
>>>>> 
>>>>> Depends on your infrastructure and how things get propagated
>>>>> between components.
>>> 
>>> There are a number of unstated assumptions here that would be
>>> worthwhile to point out.
>>> 
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> You write: " If the client does not exist on this server,
>>>>>>>> the server MUST respond with HTTP 401 Unauthorized and
>>>>>>>> the registration access token used to make this request
>>>>>>>> SHOULD be immediately revoked. "
>>>>>>>> 
>>>>>>>> If the client does not exist and someone sends a request
>>>>>>>> with a random registration access token I am not sure
>>>>>>>> what exactly you want to revoke here.
>>>>>>> 
>>>>>>> It's not the case of a random token, it's the case of a
>>>>>>> client having been deleted but using an otherwise valid
>>>>>>> access token. If the token's no good, you don't get this
>>>>>>> far -- you return a 401 as defined in RFC6750.
>>>>>> 
>>>>>> I guess it might make sense to add this information.
>>>>> 
>>>>> It’s already in there, in the paragraph just before the one you
>>>>> quoted:
>>>>> 
>>>>> If the registration access token used to make this request is
>>>>> not valid, the server MUST respond with an error as described
>>>>> in OAuth Bearer Token Usage [RFC6750
>>>>> <https://tools.ietf.org/html/rfc6750>].
>>>>> 
>>> 
>>> 
>>> But the argument that you provided is for "the case of a client
>>> having been deleted but using an otherwise valid access token" but
>>> the text you cite talks about the registration access token not
>>> being valid. Those appear to be two different cases.
>>> 
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> In Section 3.1. "Client Information Response" you state
>>>>>>>> the new elements that are returned to the client. While
>>>>>>>> the client_secret has an expires_at field the
>>>>>>>> registration_access_token doesn't. Does the expiry value
>>>>>>>> of the client_secret_expires_at automatically indicate
>>>>>>>> the lifetime of the  registration access token? I think 
>>>>>>>> so. But what happens if the client_secret is not issued?
>>>>>>>> To make it more complicated you write the following text
>>>>>>>> in the security consideration section:
>>>>>>>> 
>>>>>>>> " While the client secret can expire, the registration
>>>>>>>> access token SHOULD NOT expire while a client is still
>>>>>>>> actively registered. "
>>>>>>> 
>>>>>>> There isn't a separate expiration for the registration
>>>>>>> access token because it's not supposed to unceremoniously
>>>>>>> expire on a client. It should be good until it gets rotated
>>>>>>> out on a future read/update operation or the client's
>>>>>>> registration is no good anymore.
>>>>>> 
>>>>>> I think it might be good to have a small section that
>>>>>> explains how state management works.
>>>>> 
>>>>> Can you suggest text for this beyond the paragraph that’s
>>>>> already there?
>>> 
>>> Yes, I can do that. If you could ship a new update then I can read 
>>> through the entire document again and figure out how to create a
>>> state machine.
>>> 
>>> If you, of course, get rid of this credential rotation then I don't
>>> have to do it though.
>>> 
>>> 
>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> The IANA consideration section is empty. Wouldn't it be
>>>>>>>> necessary to register 'registration_access_token' and 
>>>>>>>> 'registration_client_uri' into the OAuth Dynamic
>>>>>>>> Registration Client Metadata Registry?
>>>>>>> 
>>>>>>> No, these are not client metadata. The client can not send
>>>>>>> these in a registration request, so they don't need to be
>>>>>>> in there.
>>>>>> 
>>>>>> Really?
>>>>>> 
>>>>>> I thought that the IANA registry created with Section 5.1 of 
>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-20 was
>>>>>> meant to be used with the Client Registration Request and the
>>>>>> Client Registration Response exchange. The
>>>>>> 'registration_access_token' and 'registration_client_uri'
>>>>>> parameters are used in the response.
>>>>>> 
>>>>>> Looking again at draft-ietf-oauth-dyn-reg-20 I noticed an
>>>>>> inconsistency: The protocol interaction should either be
>>>>>> 
>>>>>> 
>>>>>> C -> AS: Client Registration Request C <- AS: Client
>>>>>> Registration Response
>>>>>> 
>>>>>> OR
>>>>>> 
>>>>>> C -> AS: Client Registration Request C <- AS: Client
>>>>>> Registration Error Response
>>>>>> 
>>>>>> Currently, sometimes the term "Client Registration Response"
>>>>>> or "Client Information Response" is used. We need to fix this
>>>>>> since it spills over to the management API document as well.
>>>>> 
>>>>> Client Information Response and Client Error Response are
>>>>> sub-classes of Client Registration Response. If that’s not
>>>>> clear from the current document, please suggest new wording to
>>>>> make it clearer.
>>> 
>>> As a shepherd I read through both documents in detail and I didn't 
>>> figure that out. That gives me reasons to believe that others
>>> wouldn't figure that out either.
>>> 
>>> I would make the change already in Figure 1 of Dynamic Client 
>>> Registration Protocol document.
>>> 
>>> 
>>> 
>>> +--------(A)- Initial Access Token (OPTIONAL) | |   +----(B)-
>>> Software Statement (OPTIONAL) |   | v   v +-----------+
>>> +---------------+ |           |--(C)- Client Registration Request
>>> -->|    Client     | | Client or |
>>> | Registration  | | Developer |<-(D)- Client Registration
>>> Response---|   Endpoint    | |           |
>>> +---------------+ +-----------+
>>> 
>>> Client Registration Response:= Client Information Response OR 
>>> Client Error Response
>>> 
>>> Same change to Figure 1 in the dynamic client registration
>>> management document. You could even indicate in the figure which
>>> parts are already specified in the dynamic client registration spec
>>> and which are added via the dynamic client registration management
>>> doc.
>>> 
>>>>> 
>>>>>> 
>>>>>> Also, I noticed that we say that the server MUST support TLS
>>>>>> 1.2 RFC 5246 and/or TLS 1.0. We definitely cannot say TLS 1.0
>>>>>> anymore.
>>>>> 
>>>>> Kathleen made a similar comment on dyn-reg and suggested text
>>>>> that we’ll incorporate (unless there are objections from others
>>>>> on the list).
>>> 
>>> Ack.
>>> 
>>>>> 
>>>>>> 
>>>>>> In Figure 1 it might be useful to indicate that exchanges A,
>>>>>> B, C, and D are inherited from the dynamic client
>>>>>> registration document and only step D is enhanced with
>>>>>> additional parameters, as described in Section 3.1.
>>>>>> Furthermore, I wonder whether it would make sense to somehow 
>>>>>> indicate in the figure that the endpoints are actually part
>>>>>> of the Authorization Server.
>>>>> 
>>>>> While they usually are the same in practice, these endpoints
>>>>> might not be part of the Authorization Server — they might be
>>>>> part of a separate (but related) service that handles objects
>>>>> of various kinds within a security domain. No reason to tie
>>>>> them together unnecessarily.
>>> 
>>> You can state that someone in the text but endpoints by itself
>>> don't exist since they have to be at some server. Even if the
>>> endpoints are in separate boxes there needs to be a close
>>> cooperation between the two since otherwise we create new
>>> interoperability challenges.
>>> 
>>> Ciao Hannes
>>> 
>>>>> 
>>>>> — Justin
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Ciao Hannes
>>>>>> 
>>>>>>> 
>>>>>>> -- Justin
>>>>>>> 
>>>>>> 
>>>>>> _______________________________________________ OAuth mailing
>>>>>> list OAuth@ietf.org <mailto:OAuth@ietf.org> 
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> 
>>>>> _______________________________________________ OAuth mailing
>>>>> list OAuth@ietf.org <mailto:OAuth@ietf.org> 
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>> 
>>> _______________________________________________ OAuth mailing list 
>>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth