Transitioning from OpenID-based SSO to ID-WSF-based attribute exchange
From Project Concordia
Contents |
Use case description
A user Claire visits her OpenID RP and provides her OpenID URI there. Claire is taken to her OP for authentication and subsequently directed back to the RP. In the course of Claire's activities there, the RP realizes that it would be able to provide a more customized service if it were able to obtain Claire's current geolocation. Unfortunately, the OP does not have this information and so can't be asked directly. The RP can however use ID-WSF mechanisms to first discover and then invoke Claire's geolocation service to obtain the desired attributes.
Workflows
- User presents their OpenID to RP
- RP performs OpenID Discovery and fetches the XRDS document
- RP redirects User to their OP for log-in
- OP redirects User back to RP after authorization step
- RP extracts SAML IdP endpoint from XRDS document
- RP sends SAML AuthnRequest to SAML IdP
- Note that if the OP and IdP are the same, then the request could be signed with the OpenID DH shared secret
- User authenticates to IdP, if it is the same as the OP this step will be transparent
- IdP sends Response with DS EPR with the token
- RP uses DS EPR to query WSF Discovery Service for applicable service
Additional information and related work
John Kemp post - http://appliedlife.blogspot.com/2007/02/ive-been-interested-for-while-in.html
Paul Madsen post - http://connectid.blogspot.com/2007/04/openid-bootstrap-to-id-wsf.html
Related events
Contacts and contributors
Questions
- What if the Discovery Service were exchanged for the XRDS document?
- Could you please clarify? Did you mean (a) replace XRDS with the Discovery Service (DS) such that an OpenID would resolve to a DS? or (b) replace the DS with the XRDS?
- I guess he means to include the DS contact info in the XRDS? -- this would be potentially feasible, however: (a) static link, no real-time properties (b) no chance to obtain tokens for DS access on real-time
