Docstoc

01-reed-openid-xri-xrds

Document Sample
01-reed-openid-xri-xrds Powered By Docstoc
					OpenID Discovery Using
XRI and XRDS

 IDtrust Symposium, March 4-6, 2008

 Drummond Reed, Cordance
 Les Chasen, NeuStar
 William Tan, NeuStar
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         Persistent
                 “i-name(s)”         “i-number”

                             XRDS
                             Docu-     XRDS
                             ment     Resolution


              Domain Name                           Other
Concrete
                                                  concrete
Identifier      IP Address             TN
                                                  identifier
  Layer                                             types
             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)




           XRDS
         Document




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

				
DOCUMENT INFO