[OpenID] Trust + Security @ OpenID
Peter Williams
pwilliams at rapattoni.com
Tue Jul 10 22:52:05 UTC 2007
Do you have a specific use case in mind? If yes I would be interested
to know it.
---------------
Let me give a realty use case. I will use SAML terminology (because its
standard and precise, only). I map it onto OpenID as best as I can.
Realtor uses some user auth technique to logon to a MLS (a multiple
listing service) acting as an IDP. Independently, Realtor users browser
to try to logon to a service provider. User selects MLS as the chosen
IDP. The SP-initiated SAML flow provide the SP with a proof claim for a
MLS-ID, issued by the IDP. Using name-federation, the MLS-ID is mapped
on the fly by SAML to SP-ID.
Ok. So far, that's just the SAML-equivalent function of what OpenID Auth
does. For MLS substitute AOL. For Sp-initiated SAML, substituted OpenID
Auth flow. For MLS-ID, substitute URI/XRI bearing an AOL screenname.
There is no (need for) name federation in OpenID land, as opened relying
parties use URIs/XRIs natively.
Now, realtor wanders in a browser window to some form application on the
SP site. SP thus makes request of IDP for 10 user profile attributes,
and 1 "form-specific attribute". In SAML world, this is just a simple
signed Attribute Request/Response, a response to be issued by the
Attribute Authority co-resident with the IDP at MLS. The browser session on
the IDP at MLS is already sufficient to authorize access to the AA at MLS.
Ok. So far, that's just the SAML-equivalent function of what OpenID
Exchange does, when building upon an OpenID Auth session.
In Realty, the MLS (the initial IDP/AA) does not maintain form-specific
attributes, however, only personal attributes. The form attribute comes
from a second AA (known as AA at Forms), where the realtor has a
forms-management subscription. By inter-AA agreement, The AA at MLS chains
part of the original AA request to the AA at Forms. Upon getting the
response, the AA at MLS collates its own attributes with that extra
attributes managed by the AA at Forms. The Relying Party relies upon the
AA at MLS Response signature to hold the MLS accountable for the accuracy
of the attributes (even those obtained from one or more AAs, accessed
via chaining(s) behind the scenes).
The right for an AA to originate an Attribute Request itself to a second
AA that is not the IDP of the end-user relying party is the use case we
are after. I need OpenID to address this IN ITS MODEL - just as well as
SAML does.
More information about the general
mailing list