On 4/16/10 5:03 PM, "Brian Eaton" <[email protected]> wrote:
On Thu, Apr 15, 2010 at 12:38 PM, Chuck Mortimore <[email protected]> wrote: > Could you please take another glance at what I posted? There are a number > of changes to the general assertion flow that are required for it to reflect > how this will be used in a lot of scenarios. > (A) The client sends an access token request to the authorization server > and includes a self-issued assertion. Why self issued? > It really can be either, and I see now that's not really clear here. The > client may have the ability to directly issue the SAML assertion, rather than > having to fetch it from a server. In short, the profile doesn't care > about where the assertion came from, as long as it validates, and I was > attempting to convey that. This is likely confusing and probably needs > re-wording. > The value of the assertion parameter MUST be a valid SAML <Response> message Why saml Response instead of saml Assertion? > I was really back and forth on this one. I scoped it down to Response for > simplicity, but I've spoken to enough people offline that I think I probably > made the wrong choice. A new suggestion would be: "The value of the > assertion parameter MUST contain a valid SAML Assertion. The SAML Assertion > MAY be enclosed in a valid SAML Response. If enclosed in a SAML Response, > the Assertion MAY inherit it's signature from the Response per SAML Core 5.3" Scope would be useful in this profile. Adding form-encoded content-type header to the examples would be useful. Cheers, Brian > Thanks for reviewing this. -cmort
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
