Defining PAPE "active authentication" (WAS: Re: PAPE Extension Specification)

David Recordon drecordon at sixapart.com
Mon Oct 22 22:25:14 UTC 2007


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 at 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
>





More information about the specs mailing list