Re: [security-services] DAON Slide Thoughts

[Rainer Hoerbe <rainer@hoerbe.at>]

Am 03.02.2014 um 20:57 schrieb Hal Lockhart <hal.lockhart@oracle.com>:

>> So, on the last call I noted that it was unclear to me what they
>> thought the difference between a "Credentialing Service Provider" and
>> an IdP was.  After another review I'm still confused but, I think their
>> CSP may just be the authentication authority role in SAML.  I think the
>> distinction they're trying to make is that many IdPs today implement
>> both the authentication and attribute authority roles but most SPs this
>> group encountered only cared about the former.
>> 
> I went thru a similar exercise recently I concluded that most people using the term CSP mean Authentication Authority. I think a key point is that typically the SP has some attributes that they REALLY care about which they collect from the user or obtain from some authoritative source, out of band. This data is key to their value add, so they want to maintain total control of it, while they are glad (or at least willing) to farm out the Authentication task.

One reason for the ambiguity in the use of CSP and IDP is that those documents defining those terms (like X.1252, SP800-63) do not have the concept of separating verification (authenticating using an electronic credential) from assertion (of an authentication events). 
The discussion on ISO 24760-2 (Reference Architecture for IDM, CD-stage) goes into the direction that the CSP is just issuing credentials, and the IdP is a broker that is just asserting them.

Caveat: Current industry practice mixes business and technical layers. In most contexts a CSP and a Registration Authority are legal/operational entities, whereas IdPs and SPs in the SAML context are system entities. 

>> 
>> Slide 12, bullet #4 brings up geolocation within an authn request.
>> This is something we recently started needing here at Covisint as well.
>> Might be worth discussing on a call.
> 
> At least it is worth getting a clear statement of the usecase. Does this imply we have to treat a smart phone as a trusted device? If not, who is the Authority for this data? How much assurance is required? How fresh does it have to be?

The Trust Elevation TC published V1.0 of their framework that puts things like geolocation into context. Maybe the question could be deferred to them.

>> 
>> Slide 16 brings up a point that I ran face-first into here.  IdP
>> proxies/brokers are in the SAML spec if you really read it but not in
>> big bold font like other usages of the spec.  Might be worth putting in
>> some verbiage somewhere to raise the visibility a bit and make sure
>> people do "the right thing".
> 
> Here again it would be good to have a clear statement of the things that make this case different from regular SSO.
Meaning that mesh federations are regular, hub-and-spoke irregular?

> I wonder if the parties can be described by some combination of the actors defined in SAML core: Requester, Presenter, Requested Subject, Attesting Entity, Relying Party and Identity Provider. 


> 
> If so we could simply say A acts as an X and B acts as a Y and Z and the existing descriptions could stand. If we need to refactor the actors or define totally new ones, that is another matter.
> 
> Hal
> 
>> Chad La Joie
Rainer