+1 Those login and logout ceremonies giving false impression of security
probably will diminish its importance pretty quickly. I recon those more as
a privacy feature than security.
2016年2月16日(火) 9:35 Phil Hunt (IDM) :
> +1
>
>
> Phil
>
> On Feb 15, 2016, at 16:50, John Bradley wrote:
>
> The que
+1
Phil
> On Feb 15, 2016, at 16:50, John Bradley wrote:
>
> The question is what counts as re-authentication.
>
> It may be that the environment is changing. Re-prompting for a password in
> many cased just tells you the user has a form filler.
>
> It may be better to use risk based fact
In older systems, time based logout is all you have if you aren't assessing
risk.
I would think over time will quickly diminish in its importance (or as best
practice) - at least as the single method for determine a session should end
other than explicit logout.
Phil
> On Feb 15, 2016, at 1
It now shows how to return multiple endpoints in web linking.
Also, added Resource Endpoint response header.
Best,
nat
-- Forwarded message -
From:
Date: 2016年2月12日(金) 18:40
Subject: New Version Notification for draft-sakimura-oauth-meta-07.txt
To: Nov Matake , Nat Sakimura , Sa
The question is what counts as re-authentication.
It may be that the environment is changing. Re-prompting for a password in
many cased just tells you the user has a form filler.
It may be better to use risk based factors such as prompting for a pin, or
using a local passive biometric, eg ha
Polite comment, Google in general is pretty "open" about session management in
general - long idle timeout and no apparent absolute timeout. For a bank or
other organization that produces high risk software, this is not standard
practice. Re-authentication is a critical security boundary, not pr
+1 Being in the mobile space myself and constantly meeting with native app
developers I've heard my share of horror stories on how OAuth was
implemented, myself being guilty of being "creative" around OAuth.
This draft is be of great value to those of us who are around these
developers, we'll be h