Thanks for the feedback Prateek. I've tried to address some of you comments and questions inline below.
On Wed, Feb 13, 2013 at 3:53 PM, Prateek Mishra <prateek.mis...@oracle.com>wrote: > It would be helpful if the draft identified the various cases that are > intended to be supported. For example, > in draft-ietf-oauth-assertions-**10, there is a helpful distinction made > between "Client acting on behalf of a user" vs. > "Client Action on behalf of an anonymous user" (vs. even more advanced > use-cases). Otherwise, folks > have a hard time figuring out the pieces they need to implement and the > required behavior. > The guidance in ยง6 of draft-ietf-oauth-assertions-10 provides some particular details of the more general general cases and they apply here as well as the JWT draft. I'd like to avoid repeating the text and bloating the documents. > > It feels like Section 3 speaks to all of these cases simultaneously. I > think this is confusing and > our developers have raised some questions about it. > It's not really intended to speak to the cases so much as provide the required processing rules to validate the assertion in a reasonably secure way. There is some simultaneous treatment of the client authentication case and the authorization grant case because they have much more in common than they have that's different. I can make a pass at better pointing out where the differences are. > > BTW, it would also help if the rules in Section 3 were numbered. > I'll see what I can do. I assume it's possible with the xml2rfc markup but have never done it. > > 1) For the case where we have "Client acting on behalf of user" - this > case seems to be where we > have something like a SAML SSO assertion - complete with Subject > identifying the > "authorized accessor or delegate". The Client offers this bearer > instrument as an access grant and the Authorization > server understands that its "acting on behalf a user". > > a) As the SAML assertion is a bearer instrument and can be stolen, the > authorization server should insist on client credentials being present. > In other words, the client should be confidential. What is the value in > permitting a public client to participate in this exchange? > Very similar to SAML Web SSO where the client (HTTP user agent browser in that case) is unidentified and the bearer assertion is the sole token provided to identify/authenticate the subject and gain access. In some cases there is a quite a bit of value in not having to provision or manage the clients. > > b) Further, as part of its processing rules, once the client has been > authenticated > the authorization server should determine whether the particular client > has the right to present the SAML bearer assertion. > An AS is free to deploy that kind of policy as needed for the deployment or product. But the spec intentionally does not dictate any such policy. And intentionally allows for unidentified clients. > > c) What is the value of including an AuthNStatement? Specifically, what > does the Authorization server understand by its > presence or absence? What is the guidance to deployers? Should they > require end-user authentication to have taken place? > > It's intended to convey whether or not the issuer actually authenticated the subject or not. It's a distinction that, based on some conversations I'd had, seemed like it might be useful for some. But much existing SAML software doesn't work that way currently, which is why there's not a MUST there. I'm trying to accommodate existing practice, within reason, while also provide potentially useful functionality. > 2) Bullet 5 (counting from the bottom of Section 3) references a more > advanced use case based on a SAML delegation > model. Is this the ONLY case where AuthNStatement's are allowed to be > omitted? If so, that should be stated clearly. > I've got a SHOULD NOT there. I don't think a MUST is reasonable based on what I've seen actual deployments do. Please suggest some text, if you think it can be improved. > > I think this bullet refers to an advanced use-case and should be moved to > an independent section. > I think it's pretty common actually. > > I think by "the presenter act autonomously on behalf of the subject" you > mean something like "Client acts on Behalf of Anonymous Users". > as identified in draft-ietf-oauth-assertions-**10. > No. I mean that the presenter (client) is acting on behalf of the user. And the user probably isn't present for the transactions. "Autonomous" is a word that kind of got inherited from the very early OAuth 2.0 drafts ( http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-1.4.4) and maybe causes more trouble than it's worth here? > > I also found the sentence "The presented SHOULD be identified in the > <NameID> or similar element,.." problematic. Its pretty open ended > and it seems to me it will be difficult to have an interoperable > implementation based on this text. > I agree that it's confusing and I believe it's partly because there's a mistake in that text. It should say something more like "The presenter SHOULD be identified in the <NameID> or similar element *within* the <SubjectConfirmation> element, or by other available means like [ OASIS.saml-deleg-cs<http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15#ref-OASIS.saml-deleg-cs> ]" Which is less open ended but still pretty open. The <NameID> or similar text is becasue there can be a <BaseID>, <NameID>, or <EncryptedID> child of the <SubjectConfirmation> and I was trying to avoid writing all that out. The "SAML V2.0 Condition for Delegation Restriction" reference (which probably should be expanded) is to a document that came along well after regular SAML 2 and isn't widely supported, as far as I know. Neither of these ways of expressing delegation is really used much in practice, as far as I know, which makes it difficult to dictate particular requirements here. > > Finally, what are the additional processing rules that the authorization > server needs to implement when processing this class of SAML assertions? > I don't understand? That's what 3 is all about. Or should be. > > 3) Has there been any interoperability testing of this profile? This is an > activity we would be interested in. > Nothing official that I know of. I'd probably be worthwhile. But of course, there's a lot involved in something like that.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
