This response is slow but somewhat less slow than those that came before. So I also apologize again but somewhat less so :) I do apologize for sending on a weekend but I just wasn't able to finish and make it to the "send" button before the end of my Friday.
I've endeavored to continue the exchange inline below where appropriate and removed portions that needed no further discussion. On Fri, Jan 11, 2019 at 9:13 AM Benjamin Kaduk <ka...@mit.edu> wrote: > I also apologize for the slow response (I gave Brian a unicast heads-up > earlier) -- between vacation, the holidays, and a death in a the family I > was away from email for quite some time. > > On Tue, Dec 04, 2018 at 02:54:36PM -0700, Brian Campbell wrote: > > I apologize for the slow response, Ben. I was on vacation with my family > > around the Thanksgiving holiday when the ballot position came in. And > even > > on returning and starting to work on it, there's an awful lot here to get > > through and this kind of thing is very time consuming for me. But thank > you > > for the review - I've attempted to reply, as best I can, to your > > comments/questions inline below. > > > > On Wed, Nov 21, 2018 at 6:43 AM Benjamin Kaduk <ka...@mit.edu> wrote: > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-oauth-token-exchange-16: Discuss > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > <snip> > > There's two obvious routes -- first, to change the text to use placeholders > like "TBD1" or "the token-exchange URI" (e.g., as opposed to > urn:ietf:params:oauth:grant-type:token-exchange specifically) and request > that IANA allocate the specific suggested values; or > to get IANA to explicitly confirm that > these values can be registered and will be marked as pending until this > document is finalized (to prevent allocation "under our nose" by other > means). Ekr and I can help mediate any IANA interaction needed for > whatever route we end up taking, if needed. > > (Basically, this is a process concern -- the IESG should not give its stamp > of approval to a document in a state that does something we don't want > other people to do, even if the final published RFC will be able to make > these claims correctly.) > I'd then ask that the AD(s) initiate and mediate interactions with IANA to have them explicitly confirm that these values can be registered and have them somehow marked as pending until the document is finalized. > > > <snip> > > Before I start trying to tweak text, can you confirm that the actor_token > request parameter is okay to use in both delegation and impersonation > scenarios? > Yes, it's certainly okay to use the actor_token in both delegation and impersonation scenarios. It's necessary for delegation and kinda makes more sense in that scenario but could still be sent by the client and have the STS issue a new token with impersonation semantics. > > > > > > Are the privacy considerations (e.g., risk of a tailed per-request > > > error_uri) relating to the use of error_uri discussed in some other > > > document that we can refer to from this document's security > > > considerations? (I say a bit more about this in my COMMENT.) > > > > > > > I am not aware of any document with such considerations and I've searched > > the likely suspects of RFC 6749 and RFC 6819 but don't find anything. > > > > The error_uri token endpoint response parameter was defined in the > original > > OAuth 2.0 framework document (RFC 6749) and any considerations around it > > are applicable to considerably more than this document. It's also very > > rarely used in practice as far as I know. I don't think that this > document, > > which is a narrow extension of a whole framework with a series of other > > documents that use error_uri, is the appropriate place to add privacy or > > security considerations about error_uri. Perhaps > > https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ > would be > > more appropriate in scope and content? > > Oh, definitely -- I only asked if there was something existing we could > cheaply reference; this is definitely not the place to be writing this down > from scratch. Thanks for doing the search! > Just to clarify, that draft doesn't currently have anything about error_uri. However, it seems like a more appropriate place for that in terms of its scope to have any such guidance. And that, to the extent such guidance or text is needed, it should go in to that draft (which is a WG draft in progress) rather than into the token exchange draft. > > I could remove the one mention of error_uri in this document? It's usage > > would still be possible/valid by virtue of this document being an > extension > > of RFC 6749 but, out of sight and out of mind, and this doc wouldn't then > > encourage new usage of it anyway. While usage isn't really happening > anyway. > > I don't mind having the reference there; it's not really causing problems > and could potentially be helpful. We should be able to get away with a > generic reference to this class of thing elsewhere and one-sentence > description ("when a proxy or similar mechanism is in place to protect > client privacy, the error_uri mechanism can induce the client to lose some > anonymity by dereferencing a URI pointing to a third party server that can > leak information to the attacker, in a similar fashion as [ref]"). I don't > have a [ref] handy right now, though; I'll need to ask around. > If you can provide such a [ref], I can add such a sentence to the draft. But I'm still of the opinion that it would be out of place in this document. In a pinch we could fallback to analogy to open-redirector issues, though > we differ in which actors are receiving/conveying/acting on untrusted > input, and we can have issues just by making the request as opposed to the > user mis-interpreting the returned resource. But to reiterate, I'm only > looking for a brief mention that some clients might care and don't need an > exhaustive description. > Perhaps then the sentence you had above but without the "in a similar fashion as [ref]" part might suffice as the aforementioned brief mention? > > > > > > > > > Section 2.1 has: > > > audience > > > OPTIONAL. The logical name of the target service where the > client > > > intends to use the requested security token. This serves a > > > purpose similar to the "resource" parameter, but with the client > > > providing a logical name rather than a location. Interpretation > > > of the name requires that the value be something that both the > > > client and the authorization server understand. An OAuth client > > > identifier, a SAML entity identifier [OASIS.saml-core-2.0-os], an > > > OpenID Connect Issuer Identifier [OpenID.Core], or a URI are > > > examples of things that might be used as "audience" parameter > > > values. [...] > > > > > > How does the STS know what type of identifier it is supposed > > > to interpret the provided audience value as? > > > > > > > The STS will have policy and configuration for the target entities for > > which it supports the issuance of tokens to in this flow, even if/when > > those entities are different types of things. The STS will have to search > > that set of things to find the right one for the given name. In theory I > > suppose there's potential ambiguity or even name collision. But in > practice > > (as it is the STS that ultimately decides the names it supports and can > > service) I don't believe there is an actual issue. > > Okay, so at some point we're essentially just doing a lookup based on > audience string, and the type information is attached to the lookup results > (along with everything else needed). > > Do you think it makes sense to add a sentence after the non-elided quoted > portion, something like ``However, "audience" values used on a given > authorization server must be unique within that server, to ensure that they > are properly interpreted as the intended type of value.''? (I'm of course > open to other suggestions, including "just leave it as it is"; I think what > triggered me to comment here is that "both the client and the authorization > server understand" leaves open the possibility that the AS might share one > understanding of a string with one client and a different understanding of > that same string with a second client, since it's only a pairwise condition > but we probably are safer with a global condition.) > My inclination would be to "just leave it as it is" because well that's the easiest thing to do but it could also make sense to add something like that sentence you had. The idea/intent behind "both the client and the authorization server understand" was that they both understand the thing and understand the same way. > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > The document could perhaps benefit from greater clarity as to whether > > > "security token"s refer to inputs, outputs, or both, of the token > > > endpoint (for the interactions defined in this specification). > > > > > > > I have been aware of the potential need here and endeavored to be clear > > about it throughout the document without being overly repetitive or > wordy. > > I will take another pass through the text and look for opportunities to > > further clarity. But if there are specific points in the doc that you > > believe need attention, please point them out so I can be sure they get > > addressed. > > I made another quick pass, and it is better than I remembered. So thanks > for the efforts, and sorry for maligning the document! > No apology necessary! > Maybe 2.2.1's "token_type" description could reiterate "issued security > token" both times that "security token" appears instead of just the second > time, though the context really ought to be enough to make this one clear.. > Other than that, the only potential trouble I see is in the introduction > when we get a barrage of the string all at once. And even that's in > reasonable shape, with the only potential changes I see being in the first > sentence of the second paragraph, something like "capable of validing > security tokens provided to it and issuing new security tokens in > response". > Thanks for the specifics, I'll make those updates. > > <snip> <snip> <snip> > > > > > > > > > In the absence of one-time-use or other semantics specific to the > > > token type, the act of performing a token exchange has no impact on > > > the validity of the subject token or actor token. Furthermore, the > > > validity of the subject token or actor token have no impact on the > > > validity of the issued token after the exchange has occurred. > > > > > > Do we really want this strong of a statement? I suspect that in many > > > environments propagating, e.g., expiration time to the exchanged > > > credential may be desired. > > > > > > > The statement was not in any way intended to prohibit propagating > > expiration time (or other criteria) to the exchanged credential. The > > statement was added, best I can recall, in response to a question that > came > > up in a WG chair review asking if the input token(s) would somehow become > > invalid once used as input to the exchange. Or if some later expiration > or > > other invalidation of the input token(s) would somehow invalidate the new > > token. The point of the statement in the doc was to try and say that > there > > is no inherit linkage effectual relationship between the tokens outside > the > > exchange event. There could be but that's not a general property of the > STS > > protocol a would be specific to a particular token type or deployment. > > > > Does that make any more sense? Do you think the wording could/should be > > adjusted? > > That makes perfect sense for what we want to happen, yes. > > I wonder if we really want the second sentence to be saying something like > "The exchange is a one-time event and does not create a tight linkage > betwee the input and output tokens, so that (for example) while the > expiration > time of the output token may be influenced by that of the input token, > renewal or extension of the input token is not expected to be reflected in > the ouput token's properties. It may still be appropriate to propagate > token revocation events, though." (This bit about revocation is perhaps > even more interesting than expiration time, and would seem to be prevented > by the current text.) > Yeah, I kinda think that or something along those lines might be indeed be better. Propagation of revocation wasn't intended to be prevented. Rather I was just aiming to say that such propagation wasn't required or even expected. > <snip> <snip> > > > > > > > Would it be appropriate to note (here or elsewhere) that for non-JWT > > > token formats that are a binary format, the URI used for conveying them > > > needs to be associated with the semantics of base64 (or otherwise) > > > encoding them for usage with OAuth? > > > > > > > My thinking had been that it'd be more or less self-evident to the very > > small group and type of people who would ever undertake such a thing. > But a > > brief note to that effect couldn't hurt. I'll add something as such. > > > > To be clear, I wouldn't mind if you decided to leave it as is. But thanks > :) > Fair enough, thanks :) > <snip> <snip> <snip> > > > On looking at it again, I agree "May Act For" isn't a particularly good > > name nor is it helpful in understanding it. I admit to having a hard time > > with the language here. But, yeah, "May Act For" isn't very good. > > > > What about "Authorized Actor" in the parenthetical and "Authorized Actor > - > > the party that is authorized to become the actor" for the Claim > Description > > in registration? > > > > I think that's an improvement, thanks. > > Thanks for confirming, I'll make that change. > > < snip> <snip> > > > > Appendix A.1.1 > > > > > > In the following token exchange request, a client is requesting a > > > token with impersonation semantics. [...] > > > > > > What part of the request indicates that impersonation semantics are > > > requested? > > > > > > > I guess it's not explicitly requesting impersonation semantics per se but > > only a subject_token is being supplied in the request so impersonation is > > kinda implied as there is no party identified that could be delegated to. > > > > Do you think the wording should be qualified as such or otherwise > adjusted? > > I could go either way, but if I was adding something, I'd go for a > parenthetical "(with only a subject_token and no actor_token, delegation is > impossible)". > That works, I'll add that. > <snip> <snip> > > -Benjamin > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
