The preference is to have the access token for registration issued by the normal token server rather then by the registration endpoint.
In the current draft it is obtained through a unique process and must outlive the client. Phil On 2013-05-30, at 19:47, "Richer, Justin P." <jric...@mitre.org> wrote: > 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> wrote: > >> Comments inline, marked by [JR]. >> >> From: Phil Hunt [phil.h...@oracle.com] >> Sent: Thursday, May 30, 2013 5:25 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 >> >> See below. >> Phil >> >> @independentid >> www.independentid.com >> 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 >>>> 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
