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
