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

[William Denniss]

This is an interesting approach. I like that it would give an explicit
signal to the RP that, yes, the IdP received the request for max_age (i.e
no client modification), but no, it won't be revealing the auth_time.

RPs then have a choice of whether to accept such IdPs or not, and could
potentially make that decision in a dynamic way without special-case rules.

On Thu, Mar 26, 2015 at 6:43 PM Nat Sakimura <sakimura at gmail.com> wrote:

> 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
>
> _______________________________________________
> 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/20150327/01f62c77/attachment.html>