Re: [OAUTH-WG] Shepherd Review of draft-ietf-oauth-dyn-reg-management-05
Justin Richer <jricher@mit.edu> Mon, 01 December 2014 02:22 UTC
Return-Path: <jricher@mit.edu>
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 286E41A014D for <oauth@ietfa.amsl.com>; Sun, 30 Nov 2014 18:22:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Level:
X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 RU55MCIotX1Y for <oauth@ietfa.amsl.com>; Sun, 30 Nov 2014 18:22:00 -0800 (PST)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3C91A0055 for <oauth@ietf.org>; Sun, 30 Nov 2014 18:21:59 -0800 (PST)
X-AuditID: 12074423-f79b86d000000cf5-a6-547bd0c67c4e
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 7A.F0.03317.6C0DB745; Sun, 30 Nov 2014 21:21:58 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id sB12Lv6w008580; Sun, 30 Nov 2014 21:21:57 -0500
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sB12Lsn4023018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 30 Nov 2014 21:21:56 -0500
Content-Type: multipart/signed; boundary="Apple-Mail=_41375217-C74B-4C13-9A4F-005899761A21"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <4724812B-DA0A-4905-8B2D-E5FC1722DC63@mit.edu>
Date: Sun, 30 Nov 2014 21:21:54 -0500
Message-Id: <4BFAB728-BF73-4213-8CDF-CC5080695C0F@mit.edu>
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>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Mailer: Apple Mail (2.1878.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLKsWRmVeSWpSXmKPExsUixG6nonvsQnWIwaz1ghZLd95jtTj59hWb A5PH4k372TyWLPnJFMAUxWWTkpqTWZZapG+XwJXRfHQie8GSu0wVE152sjcwXlvC1MXIySEh YCLx+eU5NghbTOLCvfVANheHkMBiJomN/zZDORsZJc6ffcUM4dxkkpj29BEriMMsMIlR4tyn 1awg/bwCBhJLdm1iBrGFBQIl1jfcAZvLJqAqMX1NC9g+TgFriXOLZwDVc3CwAMX3ra8ECTMD mV8WvGeCGGMlsX7qPHaIZRcYJd69mQM2U0TAUOL6zOmsELfKS3z4cJx9AqPALGR3zEJyxyyw wUkSv/c+YIWwtSWWLXwNFTeQeNr5Cou4vsSbd3OYIGx5ie1v50DFLSUWz7zBAmHbStzqWwBV YyfxaNoi1gWM3KsYZVNyq3RzEzNzilOTdYuTE/PyUot0zfRyM0v0UlNKNzGCY85FeQfjn4NK hxgFOBiVeHgl5leHCLEmlhVX5h5ilORgUhLlPT0PKMSXlJ9SmZFYnBFfVJqTWnyIUQVo16MN qy8wSrHk5eelKonwnvMAquNNSaysSi3KhymT5mBREufd9IMvREggPbEkNTs1tSC1CCYrw8Gh JME77TxQo2BRanpqRVpmTglCmomD8xCjBAcP0HAXkBre4oLE3OLMdIj8KUZFKXHepyAJAZBE RmkeXC8sVb5iFAd6S5hXG6SKB5hm4bpfAQ1mAhrM0FwJMrgkESEl1cB45PGP/Qrf56x7dEO1 u+TSMT7JCAZmnZm7J5wK7Uk7cKlEjXNx1I+nqsEt8d8vOGY93B/XKrTT85jZfZHLtgusYo+x /kg4sn+Pv9hKj1qHW11GxeuvnNV7uP9g1m7x+Trhn0SlPQwnH4hUUl7F8U85d8/B3zdYl7I/ Vc7JzuNff+Gb+brNCfMuKLEUZyQaajEXFScCAJU8NIBwAwAA
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/GwhaL6x79N4JrumsSG7czwTEaPA
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 02:22:08 -0000
Hannes, I’ve had a chance to more thoroughly re-read both the drafts and your notes, I think you’re actually correct about the IANA registration. We register “client_id” and “client_secret”, even though they can’t be requested by the client. As such, we do need to register “registration_access_token” and the “registration_client_uri” in the registry. We’ll make sure those are in the next revision of the document. — Justin On Nov 26, 2014, at 8:32 AM, Justin Richer <jricher@MIT.EDU> 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> wrote: > >> >> On Nov 26, 2014, at 2:35 AM, Hannes Tschofenig <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> 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. >> >>> >>>>> >>>>> 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). >> >>> >>> >>>>> >>>>> 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. >> >>> >>>> >>>>> >>>>> 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? >> >>> >>>> >>>>> 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. >> >>> >>>> >>>>> >>>>> 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]. >> >> >>> >>>> >>>>> >>>>> 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? >> >>>> >>>>> >>>>> 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. >> >>> >>> 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). >> >>> >>> 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. >> >> — Justin >> >> >>> >>> Ciao >>> Hannes >>> >>>> >>>> -- Justin >>>> >>> >>> _______________________________________________ >>> 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-WG] Shepherd Review of draft-ietf-oauth-dy… Hannes Tschofenig
- Re: [OAUTH-WG] Shepherd Review of draft-ietf-oaut… Richer, Justin P.
- Re: [OAUTH-WG] Shepherd Review of draft-ietf-oaut… Hannes Tschofenig
- Re: [OAUTH-WG] Shepherd Review of draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] Shepherd Review of draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] Shepherd Review of draft-ietf-oaut… Justin Richer
- Re: [OAUTH-WG] Shepherd Review of draft-ietf-oaut… Hannes Tschofenig
- Re: [OAUTH-WG] Shepherd Review of draft-ietf-oaut… Hannes Tschofenig
- Re: [OAUTH-WG] Shepherd Review of draft-ietf-oaut… John Bradley
- Re: [OAUTH-WG] Shepherd Review of draft-ietf-oaut… Hannes Tschofenig
- Re: [OAUTH-WG] Shepherd Review of draft-ietf-oaut… John Bradley