[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Groups - hirsch-sstc-lecp-draft-04.pdf uploaded
> Not really. This solution allows a client that already knows its IdP to
> advertise that it can do this. It's saying "hey, if you give me an
> AuthnRequest, I'll get you an authentication assertion from an IdP you
> trust". It is advertising the capability to perform this profile.
AuthnRequest only ?
> > The LEC protocol can be generalized in several ways. For instance, the
> > protocol can be based entirely on web services if the client and the
> > service provider also interact via SOAP. Or it can be based entirely on
> > classical Internet standards if the client and the identity provider
> > also interact via HTTP. If its the former then we need to role this into
> > a basic SOAP profile, of latter then we need to role this into the a
> > POST profile
> 1) This is a profile, not a protocol - we're profiling the use of SAML
> for SSO with the addition of a "smart" user agent between the IdP and SP.
I'm questioning the protocol of which is being considered for profiling, so I think this is still within scope
as the document describes a protocol.
> 2) As I think Scott mentioned in the F2F, if the device and the SP are
> just talking SOAP, then they might use some other SOAP-based profile for
> doing that. Or they might talk PAOS. And as the device will have PAOS
> already, it makes more sense to just use that functionality to perform
> LECP than it does to add some other as-yet-unspecified client
> functionality. As also noted during the F2F, we also wish to enable
> "legacy" SP support, where the SP doesn't have to talk SOAP with the
> client. But the client most probably won't be running a full HTTP server
> at least in the near-term. So in my opinion, the solution offered is
> lightweight, and appropriate for performance of SAML SSO protocols by a
> wide-range of devices available both today and in the future.
PAOS may or may not be there your assuming that I use an implementation that
is already there, I'm say that PAOS may not be needed if a general SOAP client
is available and then if needed I could build a LECP or other client on top
Anthony Nadalin | work 512.436.9568 | cell 512.289.4122