Hi Michael, I apologize for being so slow in responding to this. I did not receive the first message and haven't had a chance to respond to this direct email as I've been very busy trying to get a product release out the door. I attempt to answer the questions inline below. I'm also cc'ing the OAUTH WG mailing list as these are questions that others might have too. Note there are also questions about draft-ietf-oauth-assertions-00 too.
Thanks for the review and feedback. Hopefully I can address your questions. Brian On Mon, Aug 15, 2011 at 5:50 AM, Engler, Michael <michael.eng...@sap.com> wrote: > > Hi Brian, > > possibly the previous mail was lost somewhere in the IETF mailinglists … thus > I send here again directly. I apologize if you now received it twice … J > > Greetings, > Michael > > > _____________________________________________ > From: Engler, Michael > Sent: Mittwoch, 10. August 2011 18:11 > To: 'draft-ietf-oauth-saml2-bea...@tools.ietf.org' > Cc: Doersam, Joachim > Subject: Mail regarding draft-ietf-oauth-saml2-bearer > > > Hi Brian, > > I are currently reading your latest draft on SAML bearer assertion usage in > OAuth 2. Some parts are currently unclear, and it would be great if you could > bring light into the dark J … > > In the document I read the following: “If the Assertion was issued with the > intention that the presenter act autonomously on behalf of the subject, an > <AuthnStatement> SHOULD NOT be included. The presenter SHOULD be identified > in the <NamseID> or similar element, the <SubjectConfirmation> element, or by > other available means like [OASIS.saml-deleg-cs].” > > > What does it actually mean if the presenter (= OAuth client) acts > autonomously but still on behalf of the subject? Isn’t this a contradiction? Perhaps 'autonomously' isn't the best word there and I'm open to suggestions on an alternative. What I'm trying to do is differentiate between two general cases: 1) the case where the user/resource owner is present to the client in some way and the client has authenticated the resource owner or is sufficiently confident in the authentication event and 2) the case where the client is doing something on behalf of a resource owner but the resource owner isn't present to the client and hasn't directly authenticated with the client. An example of the former case might be where the client is some web application that the resource owner has logged onto and is using at the time of this transaction. The later case might be where the client is some cron job or something that runs nightly and does something on the user or users behalf but without them being around for the transaction. > Can you elaborate more on this point why the authentication statement should > be left out here? Related to what I said above, there are cases where the resource owner hasn't authenticated with the client (or some STS) and so it seems like it makes sense to say that no claim should be made in the assertion about any type of authentication. In that case, it's really just a claim about some identity about whom this access token is being requested. > Should the SAML subject reference the resource owner, or the OAuth client in > that case? My intent is that the subject (or the subject and some of the attributes) should reference the resource owner while the delegation to the client (though it's kind of implied) can be expressed through other semantics in the assertion (that's what the second sentence from the piece of the spec you quoted is intended to cover). > > In section 3.1 you write that “If present, the authorization server MUST also > validate the client credentials.“ … > > > What is the syntax for adding the client credentials to the assertion request > in case of the SAML bearer token? Do you refer to the separate assertion > covering the client as SAML subject … or are there yet another type of client > credentials to take into account? > The means of client authentication is totally independent from the grant type being presented (true for SAML grant type but also in general). That statement is just intended to ensure that client credentials aren't ignored, if they are there. > > I would assume that the client id needs to be transferred as part of the > access token request. In draft-ietf-oauth-assertions-00 you write the > following: > The following non-normative example demonstrates an assertion being > used as an authorization grant. (line breaks are for display purposes > only): > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > > client_id=s6BhdRkqt3& > grant_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& > assertion=PHNhbWxwOl...[omitted for brevity]...ZT4 > > Why do you assume it is sufficient that the client_id is not contained within > the assertion but is “solely” added to the request? In our discussions so > far, we assumed that the client id could be transferred as an attribute > statement within the SAML assertion. This would prevent tampering with the > client id subsequently. What are your thoughts on this? I don't necessarily assume that in all cases. In some the client_id is little more than an identifier (not authentication) of the client - a hint really. Other cases might require that the client authenticate and that can be done any number of ways. I also think that client_id should be made optional in the next rev of draft-ietf-oauth-assertion (it is currently required but that, I think, is an artifact of trying to stay consistent with a draft of the core spec that is now obsolete). > Greetings, > Michael > > Dr. Michael Engler > Security & Identity Management > TIP Core Security, Connectivity, Integration > SAP AG > > Dietmar-Hopp-Allee 16 > 69190 Walldorf > T +49/6227/7-47599 > F +49/6227/78-46187 > E michael.eng...@sap.com > > Sitz der Gesellschaft/Registered Office: Walldorf, Germany > Vorstand/SAP Executive Board: Henning Kagermann (Sprecher/CEO), Léo Apotheker > (stellvertretender Sprecher/Deputy CEO), Werner Brandt, Claus Heinrich, > Gerhard Oswald, Peter Zencke > Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory Board: > Hasso Plattner > Registergericht/Commercial Register Mannheim No HRB 350269 > > Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige > vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich > erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine > Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. > Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. > Vielen Dank. > > This e-mail may contain trade secrets or privileged, undisclosed, or > otherwise confidential information. If you have received this e-mail in > error, you are hereby notified that any review, copying, or distribution of > it is strictly prohibited. Please inform us immediately and destroy the > original transmittal. Thank you for your cooperation. > > > > > > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
