On 4/16/10 5:03 PM, "Brian Eaton" wrote:
On Thu, Apr 15, 2010 at 12:38 PM, Chuck Mortimore
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 scena
On Thu, Apr 15, 2010 at 12:38 PM, Chuck Mortimore
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 t
> In terms of format, it suggests:
>
> format
>REQUIRED. The format of the assertion as defined by the authorization
>server. The format MUST be a URI which designates a profile of the
>assertion flow.
>
> I personally think this is all that is required. It would be nice if these
>
Not at all...the submission is largely focused on the generic assertion flow.
It simply adds additional detail to the current text, and clarifies/corrects
some of the expected usage patterns. There is a SAML profiling of the flow at
the end of the submission, but it's a small percentage of wh
If I recall correctly, it doesn't define the format parameter, just gives one
fixed value for the SAML flow. Either way, I am suggesting we keep the SAML
flow out of the spec, keeping just the general assertion flow, with better
format definition.
EHL
On 4/15/10 11:55 AM, "Chuck Mortimore" w
+1.
Did anyone have a chance to review the proposal I made here?I have a couple
of people from the SAML community reviewing it offline, but would welcome
feedback from this group. The sample text is attached to this post:
http://www.ietf.org/mail-archive/web/oauth/current/msg01735.html
O
The assertion flow included in the specification doesn't offer enough to
provide interop. Previous discussions ruled out the idea of offering a
single SAML 2.0 based flow.
Proposal: Leave the flow as a generic assertion flow, using SAML 2.0 as an
example, and defining the syntax/values of the form
