I don't understand any of the comments below -- it already *is* an OAuth2 protected resource without any special handling. Your access tokens can be short-lived, long-lived, federated, structured, random blobs ... totally doesn't matter. They are access tokens being used to access a normal protected resource. Full stop.
Anything else is out of scope. The lifecycle discussions at the beginning are merely examples of some ways you *could* use it and are non-normative and non-exhaustive. You seem to be asking for something that's already in the draft. -- Justin ________________________________ From: Phil Hunt [phil.h...@oracle.com] Sent: Thursday, May 30, 2013 7:31 PM To: Richer, Justin P. Cc: John Bradley; oauth@ietf.org WG Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt Phil On 2013-05-30, at 16:11, "Richer, Justin P." <jric...@mitre.org<mailto:jric...@mitre.org>> wrote: Comments inline, marked by [JR]. ________________________________ From: Phil Hunt [phil.h...@oracle.com<mailto:phil.h...@oracle.com>] Sent: Thursday, May 30, 2013 5:25 PM To: Richer, Justin P. Cc: John Bradley; oauth@ietf.org<mailto:oauth@ietf.org> WG Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt See below. Phil @independentid www.independentid.com<http://www.independentid.com> phil.h...@oracle.com<mailto:phil.h...@oracle.com> On 2013-05-30, at 2:09 PM, Justin Richer wrote: OK, I think see part of the hang up. I have not seen the scenario that you describe, where you trade a 3rd party token for a "local" token. I have seen where access tokens are federated directly at the PR. (Introspection lets you do some good things with that pattern.) But that's neither here nor there, as you can already do what you're asking for and I think I can clear things up: In your case, the "3rd party bearer assertion" is simply *not* the Initial Registration Token. It's an assertion that can be used to *get* an Initial Registration Token. The token that you get from the Token Endpoint, in your case, would be "local" from your own AS. Your registration endpoint would look at this token on the way in, know how to validate it, do whatever else it wants to with it, and process the registration. Then it would issue a Registration Access Token that to the registering client to use at the RESTful endpoint. Incidentally, that token would also be "local", just like before. How you (the client/developer) get the actual Initial Registration Token is completely and forever out of scope for the Dynamic Registration spec. [PH] Yes, the issuance of the third party bearer assertion token token would be out of scope of this spec. If however the group decides to except federated direct access tokens as registration *access* tokens, then I think we have to define federation for access tokens first. For me, I think this is something that should be discussed in a different charter. [JR] It's an access token, plain and simple. The draft doesn't care -- and shouldn't care -- if it's federated or not. I agree, and have been arguing all along, that if you have a use case for federated access tokens, you need to define the mechanisms for such tokens, and that registration is *not* the place for that definition. It's orthogonal but they can be used together. Let's define them separately but in a compatible way. [ph] thats not the impression i get from the draft. As i mentioned earlier using access token for registration is clearer. This all still fits with the current definitions as they are. You don't have to use federated tokens if you don't want to. I can still use them if I want to. Everybody's happy! And this is all because we are not defining any content or semantics tied to the processing of the Initial Registration Token or calling it an Assertion or anything -- it's up to the AS to process it however it would normally process an OAuth Access token. So if your AS needs a local token, then you need to use a local token. If you don't want to use structured foreign tokens as your Initial Registration Tokens, don't. But that shouldn't preclude others of us from doing so. [PH] The difference is where the client is expected to present the federated (aka 3rd party) assertion. I would rather follow the standard 6749 4.5 method in all cases for consistency. You can choose to short circuit, but I think the draft should follow a consistent methodology. [JR] 6749 section 4.5 (extension grants) is irrelevant to registration as it's talking about access to the token endpoint and not to protected resources. Additionally, people do use assertions encoded inside of OAuth tokens directly at protected resources all the time (since OAuth2 tokens are opaque to clients but must be understood by protected resources), but that's *still* completely irrelevant to this discussion because it doesn't matter in terms of the interoperability of the protocol. If you want to use assertions or auth codes or client credentials or magic to get your Initial Registration Token, the dynamic registration protocol doesn't care how you did it. Just like any other OAuth2 protected resource doesn't care how you got the token. This abstraction was one of the key insights in how OAuth2 is structured as a framework and protocol. The important thing here is that if the client gets an Initial Registration Token it knows where to send it and how to use it. What I hear you saying is that you don't want to use a federated token as an Initial Registration Token. That's fine! Don't do it -- and you have that option precisely because of how we've already written it! If your clients get handed a token that *isn't* an Initial Registration Token and you want them to go through another step to *get* an Initial Registration Token, so be it! But it doesn't make sense to encode that behavior as required into the registration protocol, because (as you point out) not everything is going to be an assertion in the first place. Again I say that you can do everything that you want to do with existing mechanisms or self-contained extensions. [ph] i am referring to the mechanism currently defined that accepts external assertions in exchange for access tokens within the server. When you do it this way all clients are now accessing the reg endpoint with a short term access token. If you want to make federated access tokens a formal approach you need to profile it since there is no spec for federated access tokens. IOW, handle federated access tokens the same way 6749 does which is to say nothing. If you do this you can really simplify registration because now it just normal oauth protected resource without any special handling. If you think it would be helpful, I can add language to the lifecycle discussion to clarify that the Initial Registration Token can be gotten through any number of means, not just the manual-portal approach that's talked about now. Or if you want to write up this specific use case we can add it as another concrete example. [PH] I think there is potential to cut a lot of text out of the spec if we strictly define the registration endpoint as a normal OAuth2 protected endpoint. [JR] I don't understand what you're saying here -- it already *is* an OAuth2 protected endpoint, like I've pointed out below. All OAuth2 protected endpoints don't care how you get the token, neither does this one. All OAuth2 protected endpoints don't care (from OAuth2's perspective) how the token is verified or processed, and neither does this one (from the draft's perspective). I explicitly want to keep that kind of token and assertion processing *out* of this draft because it's more useful to build generally applicable mechanisms. If we keep the registration endpoint as an OAuth2 protected endpoint -- like it already is -- then we can inherit whatever mechanisms you want, and that is a very powerful setup. I will close by pointing out that I have *never* proposed that we dictate that the Registration Endpoint have to accept and process federated tokens, and it would be ludicrous to do so. I have been and still am committed to the Initial Registration Token and the Registration Access Token being plain old opaque-to-the-client OAuth 2 tokens. [PH] Agreed. However, the use case of a 3rd party signer for client applications is critical to both commercial organizations and open source orgs that publish software that are deployed by many separate entities. The client developer needs to be able to contact the publisher in many cases to obtain a signed assertion. I believe this is a core use case. I believe as I've proposed it using the normal 4.5 exchange federated assertion for local token method, the draft doesn't have to get into the details of the assertion. Though that said, I would suggest the draft make some suggestions on the contents of such assertions. [JR] You can already do what you want to without mentioning assertions. The current draft doesn't mention assertions at all, either. All talk of use of assertions is outside the scope of registration. You're proposing adding it in, and I'm strongly against that. I think it's possible that you're still conflating the work I'm doing with the BB+ *extension* to dynamic registration with the dynamic registration document itself. I have never suggested that we pull all the extended BB+ stuff down into Dyn Reg, and in fact I think quite the opposite as I don't believe it's as generally applicable without the larger BB+ stack (which includes discovery as well as reliance on policy and other frameworks). [PH] I'm only using it as an example. Both Cisco (at IIW) and Oracle have very similar requirements. As I said above, the use case is a key use case. However I agree, the way you solve it in BB+ is not the way to solve it within the draft spec. I think the BB+ does well inform our discussions though. [JR] Considering that BB+ manages to do all of this with a cleanly defined extension without any changes in the existing draft text, I think that's as strong an argument as anything to keep it defined how it is, and that what's there is a sufficient base to build on. -- Justin On 05/30/2013 03:54 PM, Phil Hunt wrote: Justin, So far, every time an OAuth server has accepted a 3rd party token it has been a bearer assertion. The common pattern is to exchange that assertion for a an access token issued by the local server for the local resource endpoint. That's the pattern I am trying to follow. Going this way means we do not have to define the initial registration token. If however, you really want to use the initial registration token AS an access token, you are taking us into the question of using federated access tokens. I prefer not to do that here. Phil @independentid www.independentid.com<http://www.independentid.com/> phil.h...@oracle.com<mailto:phil.h...@oracle.com> On 2013-05-30, at 12:51 PM, Justin Richer wrote: I don't understand which access token is being talked about here -- is this the Initial Registration Token? Because you can already do everything below. How you get the Initial Registration token is out of scope precisely so that the AS can decide what that means. We can add language in the lifecycle discussions to bring up the fact that you can get this token from an OAuth flow, if you think that'll help clear things up. However, the client doesn't register using the client credential flow at all -- it registers using a POST to the registration endpoint, and that POST might have an OAuth token attached to it. How the client got that OAuth tok=
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
