Re: Another use-case re authentication

I had similar reaction as that of Mountie regarding the SAML use case, but I also tend to agree with Ryan. In my view, if we abstract the notion of a token, and not necessarily talk about SAML tokens (thus being constrained by the actors – IdP and SP), then it is possible to imagine cases where a 'token' is created within a browser using credentials/keys stored on the client-side. In such cases, this use case will be no different from any other signing/hashing use case.

Seetharama

On 1/8/13 7:44 PM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote:

On Tue, Jan 8, 2013 at 6:38 PM, Mountie Lee <mountie.lee@mw2.or.kr<mailto:mountie.lee@mw2.or.kr>> wrote:
SAML Identity Provider generate digital signature
and SAML Service Provider verify the signature.

normally user agent is routing data between servers (identity provider and
service provider)

being identity provider as user agent itself is
I feel risky.

the usecase can not be recommended.

I'm not entirely sure I agree here, if only because the original
request is ambiguous here. The use cases provided by
Northrop-by-way-of-Harry fail to actually describe who they view as
the actors in this. Who is authenticating against where, etc? In the
smart card credentials case, for example, why or why not is TLS auth
sufficient, etc.

The whole notion of SysApps adds another dimension, so we shouldn't be
quick to judge here.