340 likes | 506 Views
IDtrust Symposium, March 4-6, 2008 Drummond Reed, Cordance Les Chasen, NeuStar William Tan, NeuStar. OpenID Discovery Using XRI and XRDS. Overview. The OASIS XRI and XRDS specifi-cations played a key role in identity discovery for OpenID 2.0
E N D
IDtrust Symposium, March 4-6, 2008 Drummond Reed, Cordance Les Chasen, NeuStar William Tan, NeuStar OpenID Discovery UsingXRI and XRDS
Overview • The OASIS XRI and XRDS specifi-cations played a key role in identity discovery for OpenID 2.0 • We’ll explain the five key discovery challenges they helped solve • We’ll suggest potential interoperability with other identity protocols/frameworks
What is XRI (Extensible Resource Identifier)? • An OASIS Technical Committee • Started January 2003 • An open standard language for abstract structured identifiers • Identifiers that are independent of domain, application, protocol, or language • Identifiers that resolve to other identifiers • “XML for identifiers”
Synonyms XRI Layer Reassignable“i-name(s)” Persistent“i-number” XRDSDocu-ment XRDSResolution Domain Name TN Otherconcreteidentifiertypes ConcreteIdentifierLayer IP Address Local Path/Query URI/IRI
What is OpenID? • An open community specification for user-centric Internet authentication • Based on the concept that users have their own globally-resolvable identifier and OpenID authentication service • Prime use case: eliminate the need for separate usernames and passwords for different websites
Relying Party(RP) XRDSDocument OpenID Provider(OP)
Evolution from OpenID 1.x to 2.0 • OpenID 1.0 “hardwired” a URL to an OpenID identity server • This was very rigid and not extensible • As the OpenID 2.0 tent grew, it needed a more flexible and robust discovery layer
The challenges for OpenID 2.0 identity discovery • Service description • OpenID recycling • Resolution integrity and trust • Privacy and non-correlation • Extensibility
Challenge #1:Service description • Describe what versions of OpenID an OpenID identifier supports • Enable redundant, prioritized OpenID provider endpoints • Describe what other authentication protocols may be available (e.g., LID, SAML)
Service description: the solution • XRDS (Extensible Resource Descriptor Sequence) documents • The XML analog of DNS resource records • Very simple set of elements describing • Synonyms for an identifier • Service endpoints for an identifier • Expiration and trust verification metadata
<XRDS xmlns=“xri://xrds”> <XRD xmlns=“xri://xrd*($v*2.0)”> <Query>*example</Query> <Expires>2005-05-30T09:30:10Z</Expires> <ProviderID>xri://=</ProviderID> <CanonicalID>xri://=!7c4.58ff.7c9a.e285</CanonicalID> <Ref>xri://@!2017.cd67.94c8.023!c83d</Ref> <Service> <Type>xri://$res*auth*($v*2.0)</Type> <URI>http://res.example.com/=!1234.5678.a1b2.c3d4/</URI></Service> <Service><Type>http://openid.net/openid/1.1</Type> <Type>http://openid.net/openid/2.0</Type> <Path>+openid <URI>http://authn.example.com/openid/</URI> </Service> </XRD> </XRDS>
Challenge #2:OpenID recycling • With usernames/passwords usernames can be recycled • The service provider controls the binding with the credential • With OpenID, that’s no longer true • The user controls the binding to the credential • Losing control of the identifier = losing control of the credential
Challenge #2:OpenID recycling • Service providers with large name-spaces can’t afford to assign names once and lock them up forever • Examples: AOL, Yahoo • DNS names are inherently recyclable – an entire industry exists to serve the secondary domain name market
OpenID recycling: the solution • Synonyms • Support the binding of a recyclable identifier with a non-recyclable synonym • Authenticate based on the persistent synonym • Treat the recyclable identifier as only a temporary handle for the persistent synonym
OpenID recycling: the solution • Persistent synonyms is a primary raison d’être for XRI • XRI distinguishes between reassign-able “i-names” and persistent “i-numbers” at the syntax level • XRDS documents provide automated synonym mapping • XRI Resolution 2.0 includes automated synonym authorization verification
<XRDS xmlns=“xri://xrds”> <XRD xmlns=“xri://xrd*($v*2.0)”> <Query>*example</Query> <Expires>2005-05-30T09:30:10Z</Expires> <ProviderID>xri://=</ProviderID> <CanonicalID>xri://=!7c4.58ff.7c9a.e285</CanonicalID> <Ref>xri://@!2017.cd67.94c8.023!c83d</Ref> <Service> <Type>xri://$res*auth*($v*2.0)</Type> <URI>http://res.example.com/=!1234.5678.a1b2.c3d4/</URI></Service> <Service> <Type>http://openid.net/openid/1.1</Type> <Type>http://openid.net/openid/2.0</Type> <Path>+openid <URI>http://authn.example.com/openid/</URI> </Service> </XRD> </XRDS>
Challenge #3:Resolution integrity/trust • OpenID could not specify HTTPS resolution for all OpenID URLs • Too many users do not have access to HTTPS certs or infrastructure • Thus the default had to be HTTP • This forces users with HTTPS URLs to have to type the entire string, e.g., https://my.openid.identifier.tld
Resolution integrity/trust: the solution • As abstract identifiers, XRIs always map to concrete service endpoints • XRI resolution offers three trusted modes: • HTTPS, SAML, or both • Thus all XRI i-names can use HTTPS resolution as the default • No need for users to know/do anything
Challenge #4:Privacy & non-correlation • OpenID 1.x assumed users would share the same identifier(s) with every RP • Violates the Fourth Law of Identity: • A universal identity system must support both "omni-directional" identifiers for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.
Privacy & non-correlation: the solution • Directed identity • Users can enter the URL or XRI of their identity provider • The discovered XRDS doc contains a directed identity service endpoint • The RP redirects the user to their OP to select their identifier • The OP can also generate a pairwise unique “per relationship” identifier
Privacy & non-correlation: the solution • Directed identity supports means OpenID 2.0 satisfies the Fourth Law • It is the only mode some large service providers currently support • Yahoo • Ideally users will have a choice of whether to use a public or directed identifier
Challenge #5:Extensibility • OpenID is a framework for user-centric identity services • RPs need to be able to discover what OpenID extension specs an OP supports • SREG, AX, PAPE (more coming) • The discovery format itself needs to be extensible
Extensibility: the solution • XRDS documents • Service types are declared using URIs, IRIs, or XRIs – anyone can extend • Multiple types can be declared for the same service endpoint • Elements can be added from any XML namespace • XRDS documents can redirect or refer to other XRDS documents
Extensibility: the solution • Example: OAuth • “OpenID for services/applications” • Allows users to authorize a website or application to access protected resources without providing their credentials directly • OAuth Discovery uses XRDS extensibility
<XRDS xmlns="xri://$xrds"> <XRD xmlns:oauth="http://oauth.net/discovery/1.0" xmlns="xri://$xrd*($v*2.0)"> <Query>http://api.example.com/</Query> <Expires>2007-12-31T23:59:59Z</Expires> <oauth:RequestParameterMethods> <oauth:Method>AUTH-HEADER</oauth:Method> <oauth:Method>POST-BODY</oauth:Method> <oauth:Method>URL-QUERY</oauth:Method> </oauth:RequestParameterMethods> <oauth:RequestSignature> <oauth:Method>HMAC-SHA1</oauth:Method> </oauth:RequestSignature> <Service> <Type>http://oauth.net/core/1.0/endpoint/request</Type> <URI>https://api.example.com/session/request</URI> <oauth:HttpMethod>POST</oauth:HttpMethod> <oauth:RequestSignature append="head"> <oauth:Method>PLAINTEXT</oauth:Method> </oauth:RequestSignature> </Service> ...
Interoperability with other identity frameworks • SAML • Information Cards • Higgins
SAML • OpenID can use SAML! • Shown by Pat Patterson at the Internet Identity Workshop in December 2006 • Same discovery steps, similar protocol flow, just using SAML tokens • Can also use XRDS documents for automated discovery of SAML metadata
Information Cards • Information cards can carry discoverable OpenID identifiers • XRDS discovery is not used in the information card flow • But sharing an OpenID claim can enable the RP to do XRDS discovery on other identity services
Higgins • Higgins needed a solution for cross-domain context discovery • Higgins resolves a URL or XRI to an XRDS document to discover: • The service endpoint URI(s) for the context • The Higgins context configuration metadata needed to open the context
<XRDS xmlns="xri://$xrds"> <XRD xmlns="xri://$xrd*($v*2.0)"> <Query>*mycontext</Query> <Status code="100"/> <Expires>2999-01-01T00:00:00.000Z</Expires> <ProviderID>xri://@</ProviderID> <LocalID priority="10">!12345</LocalID> <CanonicalID priority="10">@!12345</CanonicalID> <Service priority="10" xmlns:hconf="http://higgins.eclipse.org/Configuration"> <Type>$context+jdbc</Type> <Type match="default" /> <URI>jdbc:postgresql://192.168.1.102/mydatabase</URI> <hconf:Configuration xmlns="http://higgins.eclipse.org/Configuration" xmlns:hconf="http://higgins.eclipse.org/Configuration"> <SettingHandlers> <SettingHandler Type="xsd:string" Class="java.lang.String" Handler="org.eclipse.higgins.configuration.xml.StringHandler"/> </SettingHandlers> <Setting Name="TestContext" Type="htf:map"> <Setting Name="username" Type="xsd:string">dbuser</Setting> <Setting Name="password" Type="xsd:string">dbpass</Setting> </Setting> </hconf:Configuration>
Future work • Caching and scalability testing • Proxying • Performance optimization • Integration with authority servers • PKI integration • Reputation discovery
Conclusions • OpenID may or may not become an Internet-wide authentication standard • But OpenID identity discovery model has already proved broad utility • XRDS resolution provides a common discovery format for URLs and XRIs • It can provide an interoperable foundation for Internet identity layer
Contact us • Drummond Reed, Co-Chair, XRI TC • http://xri.net/=drummond.reed • drummond.reed@cordance.net • Les Chasen, NeuStar, Editor, XRI TC • http://xri.net/=les.chasen • les.chasen@neustar.biz • William Tan, NeuStar, Editor, XRI TC • http://xri.net/=wil • william.tan@neustar.biz
Learn through the IDtrust Knowledgebase of educational materials and background on the standards • Share news, events, presentations, white papers, product listings, opinions, questions, and recommendations through postings, blogs, forums, and directories. • Collaborate with others online through a wiki interface http://idtrust.xml.org