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

Re: Another use-case re authentication

From: Mountie Lee <mountie.lee@mw2.or.kr>
Date: Mon, 14 Jan 2013 18:12:58 +0900
Message-ID: <CAE-+aYJ7b6koV_58iqqVD5HemdWGbZn95GZbRQjvEr15uvFBxQ@mail.gmail.com>
To: Seetharama Rao Durbha <S.Durbha@cablelabs.com>
Cc: Ryan Sleevi <sleevi@google.com>, Harry Halpin <hhalpin@w3.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
I'm saying not for the possibility but for the recommendation.
I'm sure the client itself can be the IdP even just with current
technologies.

my understanding of SAML,
Identity Provider is better when it is distinguished from service provider
or consumers.

to use these scenario (client as IdP), SP needs en-trusting operations that
registering keys sent from consumers.

the whole process will be unsafer than traditional model.

regards
mountie.

On Thu, Jan 10, 2013 at 1:59 AM, Seetharama Rao Durbha <
S.Durbha@cablelabs.com> wrote:

>  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> wrote:
>
>   On Tue, Jan 8, 2013 at 6:38 PM, Mountie Lee <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.
>
>
>


-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World

Received on Monday, 14 January 2013 09:13:48 UTC

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