[Openid-specs-ab] Spec call notes 26-Mar-15

[Nat Sakimura]

FYI, after the call, Brian, John and me  discussed this a bit more, and came to the conclusion that returning auth_time=0 may also be a good. There are times that you really do not know what it was, and in that case, returning the epic would be a reasonable thing. In google's case, it can always return auth_time=0 when asked indicating that google is unwilling to disclose this data. 
 
So, the semantics of auth_time=0 is either the IdP does not know the last active authentication time or is not willing to disclose it for various policy reasons, including both security and privacy. 

=nat via iPhone

2015/03/26 9:54、Mike Jones <Michael.Jones at microsoft.com> のメッセージ:

> Spec call notes 26-Mar-15
>  
> John Bradley
> Brian Campbell
> Nat Sakimura
> Mike Jones
> Edmund Jay
> Justin Richer
> Roland Hedberg
>  
> Agenda
>                Open Issues
>                UserInfo access passing access token in the body
>                Google not wanting to support max_age and auth_time
>                JOSE/JWT/OAuth Assertions specs status
>  
> Open Issues
>                #123: redirect_URI tests still reporting wrong results.
>                               John will close as resolved
>                No other issues were immediately pertinent to certification
>                Mike has placed two issues not needed for v1 certification on hold
>  
> UserInfo access passing access token in the body
>                It's a MAY in 6750
>                This there to enable JavaScript clients and others which may not be able add an Authorization header
>                Let's make this a WARNING rather than an ERROR now
>                In v2, we should probably add this to the Dynamic profile as required
>                Roland will make this a warning and send a note to the list when it's done
>  
> Google not wanting to support max_age and auth_time
>                Possibly reply asking if they can return an auth_time that actually reflects when the user authorized/was in possession of the device
>                User presence signal that doesn't require a password
>                               Such as a native application on a mobile device
>                A screen unlock is a valid user presence indicator
>                But device authentication time is a different semantic, which could be added, but it's different
>                Reauthentication may make more sense in the context of a particular action by the user
>                               Real-time consent for an action, as a step-up action, rather than just re-login
>                               Then the user has context for the action
>                Mike will send a response asking for more discussion
>  
> JOSE/JWT/OAuth Assertions specs status
>                These have exited RFC Editor "EDIT" status
>                They are now in "RFC-EDITOR" status: Undergoing final internal review before AUTH48
>                This means the authors will soon be asked to verify that the edited specs are correct
>                This is called AUTH48 because authors are supposed to respond within 48 hours
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150326/0d37da4d/attachment.html>