Re: [security-services] Groups - hirsch-sstc-lecp-draft-04.pdf uploaded

[John Kemp <john.kemp@nokia.com>]

Tony,

Some comments inline:

ext Anthony Nadalin wrote:

> Frederick,
> 
> I assume the goal of your proposal is to have a client (application) to 
> be able to store/retrieve knowledge of the user's IdP and use that 
> knowledge to find the IdP.
> 

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.

> 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.

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.

Cheers,

- JohnK