log inhelp

View
 

OpenID discovery for Email Like identifiers

Page history last edited by Santosh Rajan 2 years, 7 months ago

OpenID Discovery for Email like identifiers - Draft 0.1 

Background

The discovery process will follow the webfinger protocol.
The webfinger protocol is based on
Note:
All the above are very much work in progress, and any changes in the above may trigger changes in this document/protocol. This document differs from the above documents in some areas where there is still discussion on the matter, and this document may favor one view point over the other. This only reflects the authors choice on the "pending matter" and will be changed/ratified when a common decision is reached. This document does not contain anything "out of the scope" of the above documents. 

Objective

The objective of the protocol is to get the users public meta data XRD file. If not available the protocol MUST get the domain XRD file. 
Note: 
Since the host-meta file is also an XRD file, the domain XRD is merged with the host-meta XRD. 

Initiation and normalization

The end user initiates authentication by presenting a User-Supplied Identifier to the Relying Party via their User-Agent. The identifier may be a http(s) URI or an email like identifier.
  1. If the identifier does not have a scheme, test if the identifier contains an @. If not, treat it as http:
  2. If the identifier contains an @ (or an = or a $), determine whether it is: a) the first character of the identifier, or b) the first character of the path. If so, treat it to be an XRI, otherwise treat it as an email-like identifier. 

Comment from Drummond Reed, 2009-06-02: Although it is somewhat unusual for a standard http: identifier to contain an @ sign, it is in fact allowed by the RFC 3986 ABNF. Furthermore, both the XRI 2.0 and forthcoming XRI 3.0 specifications can produce http: or https: URIs that contain @ signs in the path, particularly the first segment of the path. An example is http://xri.net/@cordance*drummond.So it is not sufficient simply to look for an @ sign in an identifier to determine if it is an email-like identifier.

A better test would be:

  1. If the identifier does not have a scheme, test if the identifier contains an @. If not, treat it as http:
  2. If the identifier contains an @ (or an = or a $), determine whether it is: a) the first character of the identifier, or b) the first character of the path. If so, it is 99.9% likely to be an XRI and MUST NOT be treated like an email identifier. Otherwise treat it as an email-like identifier.

Discovery

http(s) Identifiers

If the identifier is http(s) discovery will proceed as per OpenID 2.1.

Email-like Identifiers

Host-meta

If the identifier is email like, parse it into username and domain parts and locate the host-meta XRD document for the domain.
If the domain requires https then redirect to 
https://example.org/,well-known/host-meta.xml
In case of retrieval of the host-meta XRD via http, the XRD file (MAY/MUST)? be signed and the links to the Signature and Certificate files MUST be in the XRD file.
Note:
Quoting about ",well-known" from webfinger protocol 

"The world has enough well-known URLs (/favicon.ico, /crossdomain.xml, /robots.txt), and we felt dirty adding another, so the /,wellknown/prefix is the virtual directory where we hope future specs add their well-known URLs too."

The concept of host-meta is described in the documents (2) and (3) above.  

Verifying Signature

Look for a <Link> element in the XRD file with child element <Rel>signature</Rel>. Extract the link to the signature from <URI> child element. Look for a <Link> element in the XRD file with child element <Rel>certificate</Rel>. Extract the link to the certificate from <URI> child element. Fetch the signature and certificate and verify the signature. 
Note:
Method and algo for signature to be decided? 
Comment from Drummond Reed, 2009-06-02: the XRD 1.0 team at the XRI TC is currently defining an inline signature method based on a constrained profile of XML dSig that is much easier to implement. See the thread beginning here and the thread beginning here for more info.

The user meta-data.

  • Look for a <Link> element in the XRD file with child element <Rel>me</Rel>.
  • IF FOUND
  • Extract the URI Template from the <URITemplate> child element.
  • eg. URI Template
  • http://example.org/usermeta.php?q={username}@{domain}
  • Expand the template and fetch the user meta-data XRD file.

Getting the endpoint URL.

  • IF NOT FOUND
  • Look for a <Link> element in the XRD file with child element <Rel>openid21.provider</Rel>.
  • Extract the OpenID endpoint URL from the <URI> child element.
  • This is the endpoint URL for all email like identifiers on this domain. Proceed with Authentication. Claimed Id will be the email-like identifier provided.

Getting the endpoint from the user meta-data.

  • Look for a <Link> element in the usermeta XRD file with child element <Rel>openid21.provider</Rel>.
    • If found extract the OpenID endpoint URL from the <URI> child element.
  • Look for a <Link> element in the usermeta XRD file with child element <Rel>openid21.local_id</Rel>.
    • If found extract the Local Id from the <URI> child element.
  • Proceed with Authentication. Claimed Id will be the email like identifier provided.
Note:
  1. All the text in the <Rel> elements are of my own making. We need to agree on the appropriate text and get it recognized by IETF? I think?
  2. How would the RP know if the given email like identifier was an email address or XMPP ID? May be the server must provide that information via AX?
Author: Santosh Rajan, santrajan@gmail.com.

Comments (0)

You don't have permission to comment on this page.

PDF version