PAPE Extension Specification

David Recordon drecordon at sixapart.com
Mon Oct 8 15:20:37 UTC 2007


On Oct 4, 2007, at 4:59 PM, Johnny Bufu wrote:

>
> On 4-Oct-07, at 4:27 PM, Jonathan Daugherty wrote:
>
>> # +1 on clarifying what "active" means. Before getting to wording,  
>> I'm
>> # not totally sure what would be considered active authentication and
>> # what wouldn't.
>>
>> Agreed; that should be specified, too.  If it can't be specified (I'm
>> inclined to believe it can't), then the spec should at least say
>> "whatever the OP considers 'direct authentication right now'" as
>> opposed to, say, state-based auth like a session cookie.
>
> I'm not sure I agree here. The RP is asking the OP make some
> statements about the quality of the authentication. If the request
> doesn't have the same meaning for both parties, the interaction has
> little value.
>
> If there are multiple possible definitions for what "active
> authentication" means, they can be tied to separate policy URIs.

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.

>
>> # >  - For max_auth_age, what does "in a manner fitting the requested
>> # >    policies" mean 1) in the case where no policies were requested
>> # >    and 2) in the case where authentication was performed in
>> # >    accordance with a *subset* of the requested policies?
>> #
>> # I believe auth_age in the response is meant to apply to the  
>> policies
>> # asserted in the response, rather than the ones requested.  
>> (Hinted by
>> # David's comment[1].) The RP can then see if there's a full or
>> # partial match, and decide if it's good enough.
>>
>> In that case, I think "in a manner fitting the *requested* policies"
>> (emphasis mine) should be removed entirely.  (That is, the RP is
>> imposing a limit, but it's not necessarily a limit on the type of
>> authentication it's asking for.)
>
> Either that or s/requested/asserted/.

Yes, should be asserted.

>
>> # On the same topic, I have suggested before and there seemed to be
>> # agreement[1] that it's more useful if auth_age in the response is
>> # actually a timestamp (auth_time).
>>
>> Ah, good point.  The spec didn't get changed; was there anything else
>> holding that up?
>
> Not that I know of; probably slipped off David's list.

Yep, slipped my list.  I'm happy to have you guys (Jonathan and  
Johnny) write patches (and commit) to the spec things like this.   
I'll review commits and raise any issues I see.  I think this will be  
the fastest way to guarantee the spec is in the state you guys need  
for Barcelona.

If not, I'll try to commit stuff this week.

Thanks and sorry,
--David

>
>
> Johnny
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>





More information about the specs mailing list