Frameworks that enable the SP & the IDP to have the discussion of the 'what & how' (whether that discussion happens in a board room with the suits or 'on the wire') can be categorized as:
- those that simply provide a syntax for describing technologies & processes that impact assurance, (e.g. SAML 2.0 Authentication Context)
- those that define buckets into which combinations of technologies & processes can be placed, (e.g. SAML 2.0 AC classes)
- those that define buckets into which combinations of technologies & processes can be placed, distinguished by the security characteristics they can provide (e.g OpenID PAPE)
- those that define buckets into which combinations of technologies & processes can be placed, distinguished by the level of assurance they can provide (e.g NIST 800-63 combined with OMB 04-04
4 comments:
I think the "what and how" that relying parties care most about is what happened during he registration / enrollment / identity proofing process, not how that is communicated to the relying party and not how "authentication" was performed during this transaction. In legal terms, will the identity provider assume liability if the testimony they provide turns out to be false?
NIST SP 800-63 has a lot to say about this. And I think that's what really distingishes the various levels of assurance, not the technology. So I would say that 4 is the most important, and also the most difficult, at least for higher levels of assurance.
In addition, "what & how" is only useful if the RP can trust the IdP to be "truthful".
This of course is not a problem in most SAML deployments because the COTs are based on business agreements with "liability clauses" (as Eric mentions).
It is a bigger problem with "open" networks where there is no agreement or liability arrangement. In this case the RP assumes the risk of the transaction.
Increasing confidence that an IdP is truthful about its practices is why independent audits are done, right?
True, but that "independent audit" needs to be communicated at the protocol layer in a way that can be trusted by the RP in order for the "independent audit" to do it's job.
At this point, there is no way for the RP to dynamically check the "truthfulness" of an IdP.
Post a Comment