TOC 
Network Working GroupN. Sakimura, Ed.
Internet-DraftNRI
Intended status: ExperimentalJ. Bradley
Expires: December 18, 2011Protiviti Government Services
 M. Jones
 Microsoft
 June 16, 2011


OpenID Connect Simple Web Discovery 1.0 - draft 01
draft-openid-connect-swd-0_1

Abstract

OpenID Connect is an identity framework that provides authentication, authorization, and attribute transmition capability. It allows third party attested claims from distributed sources. The specification suite consists of Core, Protocol Bindings, Dynamic Registration, Discovery, and Extensions. This specification is the "Discovery" part of the suite that defines how user and server endpoints are discovered.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on December 18, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.



Table of Contents

1.  Introduction
2.  Terminology
3.  Discovery
    3.1.  Identifier Normalization
        3.1.1.  Hostname
        3.1.2.  Email Address
        3.1.3.  URL
    3.2.  Non-Normative Examples
        3.2.1.  Hostname
        3.2.2.  Email Address
        3.2.3.  URL
    3.3.  Redirection
4.  Other Items for Consideration
5.  IANA Considerations
6.  Security Considerations
7.  Acknowledgements
8.  Normative References
§  Authors' Addresses




 TOC 

1.  Introduction

In order for an OpenID client to utilize OpenID services for a user, the client needs to know where the OpenID providers and authorization servers are located. OpenID Connect uses Simple Web Discovery (Jones, M., Ed. and Y. Goland, “Simple Web Discovery,” October 2010.) [SWD] to locate the service endpoints for a end-user. This document describes the OpenID Connect specific parts related to Simple Web Discovery (Jones, M., Ed. and Y. Goland, “Simple Web Discovery,” October 2010.) [SWD].



 TOC 

2.  Terminology

Client
An application obtaining authorization and making protected resource requests.
End-user
A human resource owner.
Principal
A human resource owner that is the target of a request in Simple Web Discovery.
OpenID Provider (OP)
Authorization Servers that are able to support OpenID Connect Messages.
Relying Party (RP)
Client and Resource Servers.
End-User Authorization Endpoint
The Authorization Server's endpoint capable of authenticating the End-User and obtaining authorization.
Client Identifier
An unique identifier that the client uses to identify itself to the OP.
Token Endpoint
The Authorization Server's HTTP endpoint capable of issuing tokens.
OP Endpoints
End-User Authentication, Authorization, and Token Endpoint.
RP Endpoints
The endpoint to which the OP responses are returned through redirect.
UserInfo Endpoint
A protected resource that when presented with a token by the client returns authorized information about the current user.
Identifier
An Identifier is either a "http" or "https" URI, (commonly referred to as a "URL" within this document), or an account URI. This document defines various kinds of Identifiers, designed for use in different contexts.


 TOC 

3.  Discovery

Simple Web Discovery requires the following information to make a discovery request:

OpendID Connect has the following discoverable services:

Service TypeURI
Authorization Endpoint http://openid.net/specs/cc/1.0/auth
   

To start discovery of OpenID end points, the end-user supplies an identifier to the client or relying party. The client performs normalization rules to the identifier to extract the principal and host. Then it makes a HTTPS request the host's Simple Web Discovery endpoint with the principal and service parameters to obtain the location of the requested service.



 TOC 

3.1.  Identifier Normalization

The user identifier can be one of the following:

Identifiers starting with the XRI (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” November 2005.) [XRI_Syntax_2.0] characters ('=','@', and '!') are reserved. Any identifier that contains the character '@' in any other position other than the first position must be treated as an email address.



 TOC 

3.1.1.  Hostname

If the identifier is the hostname, then the hostname is used as both the principal and host in Simple Web Discovery request. This results in a directed identity request.



 TOC 

3.1.2.  Email Address

If the identifier is an email address, the principal is the email address and the host is the portion to the right of the '@' character.



 TOC 

3.1.3.  URL

A URL identifier is normalized according to the following rules:



 TOC 

3.2.  Non-Normative Examples



 TOC 

3.2.1.  Hostname

To find the authorization endpoint for the given hostname, "example.com", the SWD parameters are as follows:

SWD ParameterValue
principal example.com
host example.com
service http://openid.net/specs/cc/1.0/auth

Following the SWD specification, the client would make the following request to get the discovery information:

GET /.well-known/simple-web-discovery?principal=example.com&service=http://openid.net/specs/cc/1.0/auth HTTP/1.1
Host: example.com

HTTP/1.1 200 O.K.
Content-Type: application/json

{
 "locations":["https://example.com/auth"]
}



 TOC 

3.2.2.  Email Address

To find the authorization endpoint for the given email address, "joe@example.com", the SWD parameters are as follows:

SWD ParameterValue
principal joe@example.com
host example.com
service http://openid.net/specs/cc/1.0/auth

Following the SWD specification, the client would make the following request to get the discovery information:

GET /.well-known/simple-web-discovery?principal=joe@example.com&service=http://openid.net/specs/cc/1.0/auth HTTP/1.1
Host: example.com

HTTP/1.1 200 O.K.
Content-Type: application/json

{
 "locations":["https://example.com/auth"]
}



 TOC 

3.2.3.  URL

To find the authorization endpoint for the given URL, 'https://example.com/joe", the SWD parameters are as follows:

SWD ParameterValue
principal https://example.com/joe
host example.com
service http://openid.net/specs/cc/1.0/auth

Following the SWD specification, the client would make the following request to get the discovery information:

GET /.well-known/simple-web-discovery?principal=https://example.com/joe&service=http://openid.net/specs/cc/1.0/auth HTTP/1.1
Host: example.com

HTTP/1.1 200 O.K.
Content-Type: application/json

{
 "locations":["https://example.com/auth"]
}



 TOC 

3.3.  Redirection

In cases where the SWD request is handled at a host or location other than the one derived from the end-user's identifier, the host will return a JSON object containing the new location.

GET /.well-known/simple-web-discovery?principal=joe@example.com&service=http://openid.net/specs/cc/1.0/auth HTTP/1.1
Host: example.com

HTTP/1.1 200 O.K.
Content-Type: application/json

{
 "SWD_service_redirect":
  {
   "location":"https://example.net/swd_server"
  }
}

GET /swd_server?principal=joe@example.com&service=http://openid.net/specs/cc/1.0/auth HTTP/1.1
Host: example.net

HTTP/1.1 200 O.K.
Content-Type: application/json

{
 "locations":["https://example.net/auth"]
}



 TOC 

4.  Other Items for Consideration

  1. Add other discoverable service types:
  2. Delegation
  3. Authenticated Discovery
  4. Multiple endpoint discovery in a single SWD request.
  5. HTTP/HTTPS requirement


 TOC 

5.  IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.



 TOC 

6.  Security Considerations



 TOC 

7.  Acknowledgements



 TOC 

8. Normative References

[JWS] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Signatures,” March 2011.
[JWT] Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, “JSON Web Token,” March 2011.
[OpenID.2.0] specs@openid.net, “OpenID Authentication 2.0,” 2007 (TXT, HTML).
[OpenID.AB] Sakimura, N., Ed., Bradley, J., de Madeiros, B., Ito, R., and M. Jones, “OpenID Connect Artifact Binding 1.0,” January 2011.
[OpenID.CC] Recordon, D., Sakimura, N., Bradley, J., de Madeiros, B., and M. Jones, “OpenID Connect Connect Core 1.0,” January 2011.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).
[SWD] Jones, M., Ed. and Y. Goland, “Simple Web Discovery,” October 2010.
[XRI_Syntax_2.0] Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” November 2005 (HTML, PDF).


 TOC 

Authors' Addresses

  Nat Sakimura (editor)
  Nomura Research Institute, Ltd.
Email:  n-sakimura@nri.co.jp
  
  John Bradley
  Protiviti Government Services
Email:  jbradley@mac.com
  
  Mike Jones
  Microsoft Corporation
Email:  Michael.Jones@microsoft.com