Hey David, IsPassive is an attribute on the AuthnRequest that allows the SP to indicate policy for how the user is authenticated
IsPassive [Optional] A Boolean value. If "true", the identity provider and the user agent itself MUST NOT visibly take control of the user interface from the requester and interact with the presenter in a noticeable fashion. If a value is not provided, the default is "false". It works in combination with ForceAuthn (which seems to fit with where you wre going with 'active authn' below ForceAuthn [Optional] A Boolean value. If "true", the identity provider MUST authenticate the presenter directly rather than rely on a previous security context. If a value is not provided, the default is "false". However, if both ForceAuthn and IsPassive are "true", the identity provider MUST NOT freshly authenticate the presenter unless the constraints of IsPassive can be met David Recordon wrote: > Hey Paul, > How do you guys define "passive". Seems like the opposite problem of > defining "active". > > Thanks, > --David > > On Oct 22, 2007, at 3:18 PM, Paul Madsen wrote: > >> SAML 2.0 expresses it in terms of whether or not the authentication >> is 'passive' >> >> paul >> >> David Recordon wrote: >>> Agreed with Jonathan here, don't think we need to define a policy >>> URI for "active". Rather need to clarify what is meant in section >>> 5.1. >>> (Optional) If the End User has not actively authenticated to the >>> OP within the number >>> of seconds specified in a manner fitting the requested policies, >>> the OP MUST >>> authenticate the End User for this request. >>> >>> What about? >>> Active authentication is defined as the user providing a >>> credential to the OP beyond a cookie which passively stores prior >>> authentication credentials. >>> >>> Still don't like that definition, but hopefully a few iterations >>> and we'll get there. Also asking around in the security community >>> if there is a definition for this. >>> >>> --David >>> >>> On Oct 11, 2007, at 9:33 AM, Johnny Bufu wrote: >>> >>> >>>> On 8-Oct-07, at 4:56 PM, Jonathan Daugherty wrote: >>>> >>>> >>>>> # Yep, the idea is for the PAPE spec to define a few generic and >>>>> # agreed upon policies and then RPs and OPs can create others. Thus >>>>> # if there isn't agreement on a policy, there would be multiple >>>>> policy >>>>> # URIs. Same concept as in Attribute Exchange. >>>>> >>>>> Using policy URIs to indicate certain modes of authentication is a >>>>> fine idea, but that doesn't really address the original issue: the >>>>> spec does not define "active" ("direct") authentication. >>>>> >>>> Agreed. PAPE spec should define one such policy that's acceptable >>>> for most of the OPs/RPs (and tie auth_age to it), leaving the >>>> possibility open for anyone to define other similar policies. >>>> >>>> This could be a bit tricky to specify if there's another parameter >>>> involved, but we should be able to come up with a solution. >>>> >>>> Johnny >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> specs mailing list >>> specs@openid.net >>> http://openid.net/mailman/listinfo/specs >>> >>> >>> >> >> -- >> Paul Madsen e:paulmadsen @ ntt-at.com >> NTT p:613-482-0432 >> m:613-282-8647 >> aim:PaulMdsn5 >> web:connectid.blogspot.com >> > > > > -- Paul Madsen e:paulmadsen @ ntt-at.com NTT p:613-482-0432 m:613-282-8647 aim:PaulMdsn5 web:connectid.blogspot.com _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs