- From: Mountie Lee <mountie.lee@mw2.or.kr>
- Date: Mon, 14 Jan 2013 18:12:58 +0900
- 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>
- Message-ID: <CAE-+aYJ7b6koV_58iqqVD5HemdWGbZn95GZbRQjvEr15uvFBxQ@mail.gmail.com>
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