W3C home > Mailing lists > Public > public-webcrypto@w3.org > January 2013

Re: Another use-case re authentication

From: Seetharama Rao Durbha <S.Durbha@cablelabs.com>
Date: Wed, 9 Jan 2013 16:59:57 +0000
To: Ryan Sleevi <sleevi@google.com>, Mountie Lee <mountie.lee@mw2.or.kr>
CC: Harry Halpin <hhalpin@w3.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-ID: <CD12EE9E.8BE3%s.durbha@cablelabs.com>
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.


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.
Received on Wednesday, 9 January 2013 17:00:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:15 UTC