This is good to hear. I'd really hope that the OpenID community, in specing out this extension, look at what SAML has done in the area. Additionally, I think its important that, in addition to the IDP being able to say 'This happened', the RP should be able to say 'I want this to happen'.
Avery also commented on the post. Interestingly, in describing the planned extension, he wrote:
Differentiating between (and accounting for both) how the user was registered and how they were authenticated is something SAML's Authentication Context makes possible, most notable examples of which are the 4 mobile targetted AC class URIs that differentiate based on whether the user has a contracted account or is pay-as-you-go.
about the method of identification at the point of enrollment and the method used when authenticating
In his own comment, Pete suggests:
The RP doesn't have to bother but if it chose to it could keep track of those providers that provide strong auth and act appropriately when those IdP's are the ones doing the authentication.This could work if an IDP only supported a single authentication mechanism. If not, the RP wouldn't know which was used for any given assertion.
Pete then writes
What higher level value is a claim of strong auth from an IdP when there is no trust between the IdP and the RP anyway?Indeed, but if the RP doesn't trust the IDP, its unlikely to care about how the IDP authenticated the user. And if the RP doesn't care, why would the IDP go to the extra cost and effort?
2 comments:
"This could work if an IDP only supported a single authentication mechanism. If not, the RP wouldn't know which was used for any given assertion."
True, but it will be some time before OpenID gets to the point where this is a concern.
"Indeed, but if the RP doesn't trust the IDP, its unlikely to care about how the IDP authenticated the user. And if the RP doesn't care, why would the IDP go to the extra cost and effort?"
To protect its users.
Pete, you summarized it better than I could have. Why do it? So IdPs can better protect their users... which builds community trust, which leads to the possibility of extending into scenarios where they're trusted by businesses such as banks, which moves the world from monolithic (enterprise) security to top-level defined security federations to a truly decentralized model where IdPs will build bonds of trust with eachother and with the RP/Consumers in an organic fashion based on their needs and goals.
...and yes, I know that's a hell of a run-on sentence.
Post a Comment