| TOC |
|
OpenID Authentication provides a way to prove that an end user controls an Identifier. It does this without the Relying Party needing access to end user credentials such as a password or to other sensitive information such as an email address.
OpenID is decentralized. No central authority must approve or register Relying Parties or OpenID Providers. An end user can freely choose which OpenID Provider to use, and can preserve their Identifier if they switch OpenID Providers.
While nothing in the protocol requires JavaScript or modern browsers, the authentication scheme plays nicely with "AJAX"-style setups. This means an end user can prove their Identity to a Relying Party without having to leave their current Web page.
OpenID Authentication uses only standard HTTP(S) requests and responses, so it does not require any special capabilities of the User-Agent or other client software. OpenID is not tied to the use of cookies or any other specific mechanism of Relying Party or OpenID Provider session management. Extensions to User-Agents can simplify the end user interaction, though are not required to utilize the protocol.
The exchange of profile information, or the exchange of other information not covered in this specification, can be addressed through additional service types built on top of this protocol to create a framework. OpenID Authentication is designed to provide a base service to enable portable, user-centric digital identity in a free and decentralized manner.
1.
Requirements Notation and Conventions
2.
Terminology
3.
Protocol Overview
4.
Data Formats
4.1.
Protocol Messages
4.2.
Integer Representations
5.
Communication Types
5.1.
Direct Communication
5.2.
Indirect Communication
6.
Generating Signatures
6.1.
Procedure
6.2.
Signature Algorithms
7.
Initiation and Discovery
7.1.
Initiation
7.2.
Normalization
7.3.
Discovery
8.
Establishing Associations
8.1.
Association Session Request
8.2.
Association Session Response
8.3.
Association Types
8.4.
Association Session Types
9.
Requesting Authentication
9.1.
Request Parameters
9.2.
Realms
9.3.
Immediate Requests
10.
Responding to Authentication Requests
10.1.
Positive Assertions
10.2.
Negative Assertions
11.
Verifying Assertions
11.1.
Verifying the Return URL
11.2.
Verifying Discovered Information
11.3.
Checking the Nonce
11.4.
Verifying Signatures
11.5.
Identifying the end user
12.
Extensions
13.
Discovering OpenID Relying Parties
14.
OpenID Authentication 1.1 Compatibility
14.1.
Changes from OpenID Authentication 1.1
14.2.
Implementing OpenID Authentication 1.1 Compatibility
15.
Security Considerations
15.1.
Preventing Attacks
15.2.
User-Agents
15.3.
User Interface Considerations
15.4.
HTTP and HTTPS URL Identifiers
15.5.
Denial of Service Attacks
15.6.
Protocol Variants
Appendix A.
Examples
Appendix A.1.
Normalization
Appendix A.2.
OP-Local Identifiers
Appendix A.3.
XRDS
Appendix A.4.
HTML Identifier Markup
Appendix A.5.
XRI CanonicalID
Appendix B.
Diffie-Hellman Key Exchange Default Value
Appendix C.
Acknowledgements
16.
Normative References
§
Author's Address
| TOC |
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 [RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .).
Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.
| TOC |
- Identifier:
- An Identifier is either a "http" or "https" URI, (commonly referred to as a "URL" within this document), or an XRI (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” .) [XRI_Syntax_2.0]. This document defines various kinds of Identifiers, designed for use in different contexts.
- User-Agent:
- The end user's Web browser which implements HTTP/1.1 [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” .).
- Relying Party:
- RP. A Web application that wants proof that the end user controls an Identifier.
- OpenID Provider:
- OP. An OpenID Authentication server on which a Relying Party relies for an assertion that the end user controls an Identifier.
- OP Endpoint URL:
- The URL which accepts OpenID Authentication protocol messages, obtained by performing discovery on the User-Supplied Identifier.
- OP Identifier:
- An Identifier for an OpenID Provider.
- User-Supplied Identifier:
- An Identifier that was presented by the end user to the Relying Party, or selected by the user at the OpenID Provider. During the initiation phase of the protocol, an end user may enter either their own Identifier or an OP Identifier. If an OP Identifier is used, the OP may then assist the end user in selecting an Identifier to share with the Relying Party.
- Claimed Identifier:
- An Identifier that the end user claims to own; the overall aim of the protocol is verifying this claim. The Claimed Identifier is either:
- The Identifier obtained by normalizing (Normalization) the User-Supplied Identifier, if it was an URL.
- The CanonicalID (XRI and the CanonicalID Element), if it was an XRI.
- OP-Local Identifier:
- An alternate Identifier for an end user that is local to a particular OP and thus not necessarily under the end user's control.
| TOC |
| TOC |
| TOC |
The OpenID Authentication protocol messages are mappings of plain-text keys to plain-text values. The keys and values permit the full Unicode character set (UCS). When the keys and values need to be converted to/from bytes, they MUST be encoded using UTF-8 (Yergeau, F., “UTF-8, a transformation format of Unicode and ISO 10646,” .) [RFC3629].
Messages MUST NOT contain multiple parameters with the same name.
Throughout this document, all OpenID message parameters are REQUIRED, unless specifically marked as OPTIONAL.
| TOC |
A message in Key-Value form is a sequence of lines. Each line begins with a key, followed by a colon, and the value associated with the key. The line is terminated by a single newline (UCS codepoint 10, "\n"). A key or value MUST NOT contain a newline and a key also MUST NOT contain a colon.
Additional characters, including whitespace, MUST NOT be added before or after the colon or newline. The message MUST be encoded in UTF-8 to produce a byte string.
Key-Value Form encoding is used for signature calculation and for direct responses (Direct Response) to Relying Parties.
| TOC |
When a message is sent to an HTTP server, it MUST be encoded using a form encoding specified in Section 17.13.4 of [HTML401] (W3C, “HTML 4.01 Specification,” .). Likewise, if the "Content-Type" header is included in the request headers, its value MUST also be such an encoding.
All of the keys in the request message MUST be prefixed with "openid.". This prefix prevents interference with other parameters that are passed along with the OpenID Authentication message. When a message is sent as a POST, OpenID parameters MUST only be sent in, and extracted from, the POST body.
All messages that are sent as HTTP requests (GET or POST) MUST contain the following fields:
Value: "http://specs.openid.net/auth/2.0"
This particular value MUST be present for the request to be a valid OpenID Authentication 2.0 request. Future versions of the specification may define different values in order to allow message recipients to properly interpret the request.
If this value is absent or set to one of "http://openid.net/signon/1.1" or "http://openid.net/signon/1.0", then this message SHOULD be interpreted using OpenID Authentication 1.1 Compatibility mode (OpenID Authentication 1.1 Compatibility).
Value: Specified individually for each message type.
The "openid.mode" parameter allows the recipient of the message to know what kind of message it is processing. If "openid.mode" is absent, the party processing the message SHOULD assume that the request is not an OpenID message.
This model applies to messages from the User-Agent to both the Relying Party and the OP, as well as messages from the Relying Party to the OP.
| TOC |
Non-normative
The following examples encode the following information:
Key | Value --------+--------------------------- mode | error error | This is an example message
Key-Value Form encoded:
mode:error error:This is an example message
x-www-urlencoded, as in a HTTP POST body or in a URL's query string ([RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) section 3):
openid.mode=error&openid.error=This%20is%20an%20example%20message
| TOC |
Arbitrary precision integers MUST be encoded as big-endian signed two's complement binary strings. Henceforth, "btwoc" is a function that takes an arbitrary precision integer and returns its shortest big-endian two's complement representation. All integers that are used with Diffie-Hellman Key Exchange are positive. This means that the left-most bit of the two's complement representation MUST be zero. If it is not, implementations MUST add a zero byte at the front of the string.
Non-normative example:
Base 10 number | btwoc string representation ---------------+---------------------------- 0 | "\x00" 127 | "\x7F" 128 | "\x00\x80" 255 | "\x00\xFF" 32768 | "\x00\x80\x00"
| TOC |
| TOC |
Direct communication is initiated by a Relying Party to an OP endpoint URL. It is used for establishing associations (Establishing Associations) and verifying authentication assertions (Verifying Directly with the OpenID Provider).
| TOC |
The message MUST be encoded as a POST body, as specified by Section 4.1.2 (HTTP Encoding).
All direct requests are HTTP POSTs, and so contain the required fields listed in Section 4.1.2 (HTTP Encoding).
| TOC |
The body of a response to a Direct Request (Direct Request) consists of an HTTP Response body in Key-Value Form (Key-Value Form Encoding). The content-type of the response SHOULD be "text/plain".
All Key-Value form message MUST contain the following field:
Value: "http://specs.openid.net/auth/2.0"
This particular value MUST be present for the response to be a valid OpenID 2.0 response. Future versions of the specification may define different values in order to allow message recipients to properly interpret the request.
If this value is absent or set to one of "http://openid.net/signon/1.1" or "http://openid.net/signon/1.0", then this message SHOULD be interpreted using OpenID Authentication 1.1 Compatibility mode (OpenID Authentication 1.1 Compatibility).
| TOC |
A server receiving a valid request MUST send a response with an HTTP status code of 200.
| TOC |
If a request is malformed or contains invalid arguments, the server MUST send a response with a status code of 400. The response body MUST be a Key-Value Form (Key-Value Form Encoding) message with the following fields:
As specified in Section 5.1.2 (Direct Response).
Value: A human-readable message indicating the cause of the error.
Value: (optional) Contact address for the administrator of the sever. The contact address may take any form, as it is intended to be displayed to a person.
Value: (optional) A reference token, such as a support ticket number or a URL to a news blog, etc.
The OP MAY add additional fields to this response.
| TOC |
In indirect communication, messages are passed through the User-Agent. This can be initiated by either the Relying Party or the OP. Indirect communication is used for authentication requests (Requesting Authentication) and authentication responses (Responding to Authentication Requests).
There are two methods for indirect communication: HTTP redirects and HTML form submission. Both form submission and redirection require that the sender know a recipient URL and that the recipient URL expect indirect messages, as specified in Section 4.1.2 (HTTP Encoding). The initiator of the communication chooses which method of indirect communication is appropriate depending on capabilities, message size, or other external factors.
All indirect messages arrive as HTTP requests, and so contain the required fields listed in Section 4.1.2 (HTTP Encoding).
| TOC |
Data can be transferred by issuing a 302, 303, or 307 HTTP Redirect to the end user's User-Agent. The redirect URL is the URL of the receiver with the OpenID Authentication message appended to the query string, as specified in Section 4.1.2 (HTTP Encoding).
| TOC |
A mapping of keys to values can be transferred by returning an HTML page to the User-Agent that contains an HTML form element. Form submission MAY be automated, for example by using JavaScript.
The <form> element's "action" attribute value MUST be the URL of the receiver. Each Key-Value pair MUST be included in the form as an <input> element. The key MUST be encoded as the "name" attribute and the value as the "value" attribute, such that the User-Agent will generate a message as specified in Section 4.1.2 (HTTP Encoding) when the form is submitted. The form MUST include a submit button.
| TOC |
In the case of a malformed request, or one that contains invalid arguments, the OpenID Provider MUST redirect the User-Agent to the "openid.return_to" URL value if the value is present and it is a valid URL.
As specified in Section 4.1.2 (HTTP Encoding).
Value: "error"
Value: A human-readable message indicating the cause of the error.
Value: (optional) Contact address for the administrator of the sever. The contact address may take any form, as it is intended to be displayed to a person.
Value: (optional) A reference token, such as a support ticket number or a URL to a news blog, etc.
The server MAY add additional keys to this response.
If the malformed or invalid message is received by the Relying Party, or "openid.return_to" is not present or its value is not a valid URL, the server SHOULD return a response to the end user indicating the error and that it is unable to continue.
| TOC |
The most common usage of an association is as a Message Authentication Code (MAC) key used to sign OpenID Authentication messages.
When generating MAC keys, the recommendations in [RFC1750] (Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” .) SHOULD be followed.
| TOC |
To generate a message signature:
| TOC |
OpenID Authentication supports two signature algorithms:
If supported, the use of HMAC-SHA256 is RECOMMENDED.
| TOC |
| TOC |
To initiate OpenID Authentication, the Relying Party SHOULD present the end user with a form that has a field for entering a User-Supplied Identifier.
The form field's "name" attribute SHOULD have the value "openid_identifier", so that User-Agents can automatically determine that this is an OpenID form. Browser extensions or other software that support OpenID Authentication may not detect a Relying Party's support if this attribute is not set appropriately.
| TOC |
The end user's input MUST be normalized into an Identifier, as follows:
See normalization example (Normalization).
| TOC |
Discovery is the process where the Relying Party uses the Identifier to look up ("discover") the necessary information for initiating requests. OpenID Authentication has three paths through which to do discovery:
| TOC |
Upon successful completion of discovery, the Relying Party will have one or more sets of the following information (see the Terminology section (Terminology) for definitions). If more than one set of the following information has been discovered, the precedence rules defined in [XRI_Resolution_2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .) are to be applied.
If the end user did not enter an OP Identifier, the following information will also be present:
If the end user entered an OP Identifier, there is no Claimed Identifier. For the purposes of making OpenID Authentication requests, the value "http://specs.openid.net/auth/2.0/identifier_select" MUST be used as both the Claimed Identifier and the OP-Local Identifier when an OP Identifier is entered.
| TOC |
If XRI or Yadis discovery was used, the result will be an XRDS Document. This is an XML document with entries for services that are related to the Identifier. It is defined in Section 3 of (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .) [XRI_Resolution_2.0]. See Appendix A.3 (XRDS) for an example XRDS document.
| TOC |
| TOC |
An OP Identifier Element is an <xrd:Service> element with the following information:
- An <xrd:Type> tag whose text content is "http://specs.openid.net/auth/2.0/server".
- An <xrd:URI> tag whose text content is the OP Endpoint URL
| TOC |
A Claimed Identifier Element is an <xrd:Service> element with the following information:
- An <xrd:Type> tag whose text content is "http://specs.openid.net/auth/2.0/signon".
- An <xrd:URI> tag whose text content is the OP Endpoint URL.
- An <xrd:LocalID> tag (optional) whose text content is the OP-Local Identifier.
| TOC |
Once the Relying Party has obtained an XRDS document, it MUST first search the document (following the rules described in [XRI_Resolution_2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .)) for an OP Identifier Element. If none is found, the RP will search for a Claimed Identifier Element.
| TOC |
When the Identifier is an XRI, the <xrd:XRD> element that contains the OpenID Authentication <xrd:Service> element MUST also contain a <CanonicalID> element. The content of this element MUST be used as the Claimed Identifier (see Section 11.5 (Identifying the end user)). This is a vital security consideration because a primary purpose of the <CanonicalID> element is to assert a persistent identifier that will never be reassigned, thus preventing the possibility of an XRI being ("taken over") by a new registrant.
The Relying Party MUST confirm that the provider of the XRD that contains the <CanonicalID> element is authoritative for that Canonical ID and that this XRDS document is authoritative for the OpenID Service Element. Relying Parties should either do this manually or ensure that their resolver does this.
When using XRI resolution, the Canonical ID MUST be used as the Claimed Identifier. For an XRI to be a valid Identifier, both the <ProviderID> and <CanonicalID> MUST be present in the discovered XRDS document.
When using URL Identifiers, the CanonicalID element MUST be ignored if present.
| TOC |
The "openid" namespace is no longer used as of OpenID Authentication 2.0. The "xrd" namespace is "xri://$xrd*($v*2.0)".
For compatibility with deployed code, it is RECOMMENDED that Relying Parties also accept "http://openid.net/signon/1.0" or "http://openid.net/signon/1.1" for the value of <xrd:Type>, as described in the OpenID Authentication 1.1 Compatibility mode (OpenID Authentication 1.1 Compatibility) section. It is RECOMMENDED that Relying Parties supporting OpenID Authentication 2.0 choose to use, if available, endpoints with the type "http://specs.openid.net/auth/2.0/server" and "http://specs.openid.net/auth/2.0/signon", in this order, as specified in Section <IP_ADDRESS> (Extracting Authentication Data)
If an OP supports extensions (Section 12 (Extensions)), the extensions SHOULD be listed as additional <xrd:Type> child elements of the <xrd:Service> element.
| TOC |
HTML-Based discovery MUST be supported by Relying Parties. HTML-Based discovery is only usable for discovery of Claimed Identifiers. OP Identifiers must be XRIs or URLs that support XRDS discovery.
To use HTML-Based discovery, an HTML document MUST be available at the URL of the Claimed Identifier. Within the HEAD element of the document:
A LINK element MUST be included with attributes "rel" set to "openid2.provider" and "href" set to an OP Endpoint URL
A LINK element MAY be included with attributes "rel" set to "openid2.local_id" and "href" set to the end user's OP-Local Identifier
The protocol version when HTML discovery is performed is "http://specs.openid.net/auth/2.0/signon".
The host of the HTML document MAY be different from the end user's OP's host.
The "openid2.provider" and "openid2.local_id" URLs MUST NOT include entities other than "&", "<", ">", and """. Other characters that would not be valid in the HTML document or that cannot be represented in the document's character encoding MUST be escaped using the percent-encoding (%xx) mechanism described in [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .).
As discussed in the OpenID Authentication 1.1 Compatibility mode (OpenID Authentication 1.1 Compatibility) section, these discovery tags are not the same as in previous versions of the protocol. While the same data is conveyed, the names have changed which allows a Relying Party to determine the protocol version being used. A Relying Party MAY encounter a Claimed Identifier which uses HTML-Based Discovery to advertise both version 1.1 and 2.0 Providers.
| TOC |
An association between the Relying Party and the OpenID Provider establishes a shared secret between them, which is used to verify subsequent protocol messages and reduce round trips.
It is RECOMMENDED that a Relying Party form associations if it is possible for it to do so. If a Relying Party is incapable of creating or storing associations, Section 11.4.2 (Verifying Directly with the OpenID Provider) provides an alternate verification mechanism referred to as Stateless Mode.
| TOC |
An association session is initiated by a direct request (Direct Communication) from a Relying Party to an OP Endpoint URL with the "openid.mode" key having the value of "associate".
| TOC |
These parameters are common to all association requests:
As specified in Section 4.1.2 (HTTP Encoding).
Value: "associate"
The preferred association type. The association type defines the algorithm to be used to sign subsequent messages.
Value: A valid association type from Section 8.3 (Association Types)
The preferred association session type. This defines the method used to encrypt the association's MAC key in transit.
Value: A valid association session type from Section 8.4 (Association Session Types).
Note: Unless using transport layer encryption, "no-encryption" MUST NOT be used.
| TOC |
The following parameters are common to requests whose requested association session type is "DH-SHA1" or "DH-SHA256":
Value: base64(btwoc(p))
Default: See Appendix B (Diffie-Hellman Key Exchange Default Value)
Value: base64(btwoc(g))
Default: g = 2
Value: base64(btwoc(g ^ xa mod p))
See Section 8.4.2 (Diffie-Hellman Association Sessions) for more information on these parameters.
NOTE: The 'btwoc' function is defined in Section 4.2 (Integer Representations).
| TOC |
An association session response is a direct response from the OP to the Relying Party in Key-Value Form (Key-Value Form Encoding).
| TOC |
As specified in Section 5.1.2 (Direct Response).
The association handle is used as a key to refer to this association in subsequent messages.
Value: A string 255 characters or less in length. It MUST consist only of ASCII characters in the range 33-126 inclusive (printable non-whitespace characters).
The value of the "openid.session_type" parameter from the request. If the OP is unwilling or unable to support this association type, it MUST return an unsuccessful response (Unsuccessful Response Parameters).
The value of the "openid.assoc_type" parameter from the request. If the OP is unwilling or unable to support this association type, it MUST return an unsuccessful response (Unsuccessful Response Parameters).
The lifetime, in seconds, of this association. The Relying Party MUST NOT use the association after this time has passed.
Value: An integer, represented in base 10 ASCII.
| TOC |
The MAC key (shared secret) for this association, Base 64 (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” .) [RFC3548] encoded.
| TOC |
Value: base64(btwoc(g ^ xb mod p))
Description: The OP's Diffie-Hellman public key.
Value: base64(H(btwoc(g ^ (xa * xb) mod p)) XOR MAC key)
Description: The MAC key (shared secret), encrypted with the secret Diffie-Hellman value. H is either "SHA1" or "SHA256" depending on the session type.
NOTE: The 'btwoc' function is defined in Section 4.2 (Integer Representations)
| TOC |
If the OP does not support a session type or association type, it MUST respond with a direct error message indicating that the association request failed. If there is another association session type or association type that is supported, the OP SHOULD include that information in the response.
As specified in Section 5.1.2 (Direct Response).
Value: A human-readable message indicating why the association request failed.
Value: "unsupported-type"
Value: (optional) A valid association session type from Section 8.4 (Association Session Types) that the OP supports.
Value: (optional) An association type supported by the OP from Section 8.3 (Association Types).
Upon receipt of an "unsupported-type" response, the Relying Party MAY make another request with the specified association session type and association type. If no association is established, the Relying Party MAY continue the authentication process in Direct Verification (Verifying Directly with the OpenID Provider).
| TOC |
| TOC |
An association of type "HMAC-SHA1" uses the HMAC-SHA1 (Signature Algorithms) signature algorithm.
| TOC |
An association of type "HMAC-SHA256" uses the HMAC-SHA256 (Signature Algorithms) signature algorithm.
| TOC |
OpenID Authentication defines three valid association session types: "no-encryption", "DH-SHA1", and "DH-SHA256".
| TOC |
In a "no-encryption" association session, the OP sends the association MAC key in plain-text to the Relying Party. This makes it possible for an eavesdropper to intercept the key, and forge messages to this Relying Party when not using transport layer encryption. Therefore, "no-encryption" association sessions MUST NOT be used unless the messages are using transport layer encryption. See Section 15.1.1 (Eavesdropping Attacks) for more information.
The MAC key sent by the OP MUST be the length specified for the requested association type, as specified in Section 6.2 (Signature Algorithms).
| TOC |
The "DH-SHA1" and "DH-SHA256" association types use Diffie-Hellman Key Exchange to securely transmit the shared secret.
The MAC key MUST be the same length as the output of H, the hash function - 160 bits (20 bytes) for DH-SHA1 or 256 bits (32 bytes) for DH-SHA256, as well as the output of the signature algorithm of this association.
The Relying Party specifies a modulus, p, and a generator, g. The Relying Party chooses a random private key xa and OpenID Provider chooses a random private key xb, both in the range [1 .. p-1]. The shared secret used to encrypt the MAC key is thus g ^ (xa * xb) mod p = (g ^ xa) ^ xb mod p = (g ^ xb) ^ xa mod p. For more information, see [RFC2631] (Rescorla, E., “Diffie-Hellman Key Agreement Method,” .). For information on the selection of random values, see [RFC1750] (Eastlake, D., Crocker, S., and J. Schiller, “Randomness Recommendations for Security,” .).
| TOC |
Once the Relying Party has successfully performed discovery and (optionally) created an association with the discovered OP Endpoint URL, it can send an authentication request to the OP to obtain an assertion. An authentication request is an indirect request (Indirect Communication).
| TOC |
As specified in Section 4.1.2 (HTTP Encoding).
Value: "checkid_immediate" or "checkid_setup"
Note: If the Relying Party wishes the end user to be able to interact with the OP, "checkid_setup" should be used. An example of a situation where interaction between the end user and the OP is not desired is when the authentication request is happening asynchronously in JavaScript.
Value: (optional) The Claimed Identifier.
"openid.claimed_id" and "openid.identity" SHALL be either both present or both absent. If neither value is present, the assertion is not about an identifier, and will contain other information in its payload, using extensions (Extensions).
It is RECOMMENDED that OPs accept XRI identifiers with or without the "xri://" prefix, as specified in the Normalization (Normalization) section.
Value: (optional) The OP-Local Identifier.
If a different OP-Local Identifier is not specified, the claimed identifier MUST be used as the value for openid.identity.
Note: If this is set to the special value "http://specs.openid.net/auth/2.0/identifier_select" then the OP SHOULD choose an Identifier that belongs to the end user. This parameter MAY be omitted if the request is not about an identifier (for instance if an extension is in use that makes the request meaningful without it; see openid.claimed_id above).
Value: (optional) A handle for an association between the Relying Party and the OP that SHOULD be used to sign the response.
Note: If no association handle is sent, the transaction will take place in Stateless Mode (Verifying Directly with the OpenID Provider).
Value: (optional) URL to which the OP SHOULD return the User-Agent with the response indicating the status of the request.
Note: If this value is not sent in the request it signifies that the Relying Party does not wish for the end user to be returned.
Note: The return_to URL MAY be used as a mechanism for the Relying Party to attach context about the authentication request to the authentication response. This document does not define a mechanism by which the RP can ensure that query parameters are not modified by outside parties; such a mechanism can be defined by the RP itself.
Value: (optional) URL pattern the OP SHOULD ask the end user to trust. See Section 9.2 (Realms). This value MUST be sent if openid.return_to is omitted.
Default: return_to URL
| TOC |
A "realm" is a pattern that represents the part of URL-space for which an OpenID Authentication request is valid. A realm is designed to give the end user an indication of the scope of the authentication request. OPs SHOULD present the realm when requesting the end user's approval for an authentication request. The realm SHOULD be used by OPs to uniquely identify Relying Parties. For example, OPs MAY use the realm to allow the end user to automate approval of authentication requests.
A realm pattern is a URL, with the following changes:
A URL matches a realm if:
When present, the "openid.return_to" URL MUST match the "openid.realm", or the OP MUST return an indirect error response (Indirect Error Responses).
It is RECOMMENDED that OPs protect their users from making assertions with overly-general realms, like http://*.com/ or http://*.co.uk/. Overly general realms can be dangerous when the realm is used for identifying a particular Relying Party. Whether a realm is overly-general is at the discretion of the OP.
| TOC |
OpenID providers SHOULD verify that the return_to URL specified in the request is an OpenID relying party endpoint. To verify a return_to URL, obtain the relying party endpoints for the realm by performing discovery on the relying party (Discovering OpenID Relying Parties). As always when performing discovery, the discovered URL is the URL of the last HTTP response, following redirects. If any redirects are followed when performing discovery on the realm, verification has failed. If discovery has successfuly completed, check to make sure that the return_to URL matches one of the relying party endpoints.
A realm may contain a wildcard, and so may not be a valid URL. In that case, perform discovery on the URL obtained by substituting "www" for the wildcard in the realm.
To match a return_to URL against a relying party endpoint, use the same rules as for matching the return_to URL against the realm, treating the relying party's endpoint URL as the realm. Relying party endpoint URLs MUST NOT contain a domain wildcard, and SHOULD be as specific as possible.
If verification is attempted and fails, the provider SHOULD NOT send a positive assertion to that return_to URL.
Providers MAY cache verified return_to URLs.
| TOC |
When requesting authentication, the Relying Party MAY request that the OP not interact with the end user. In this case the OP MUST respond immediately with either an assertion that authentication is successful, or a response indicating that the request cannot be completed without further user interaction. This is accomplished by an authentication request with "openid.mode" set to "checkid_immediate".
| TOC |
When an authentication request comes from the User-Agent via indirect communication (Indirect Communication), the OP SHOULD determine that an authorized end user wishes to complete the authentication. If an authorized end user wishes to complete the authentication, the OP SHOULD send a positive assertion (Positive Assertions) to the Relying Party.
Methods of identifying authorized end users and obtaining approval to return an OpenID Authentication assertion are beyond the scope of this specification. See Section <IP_ADDRESS> (Rogue Relying Party Proxying) for OpenID Provider security considerations.
If the relying party requested OP-driven identifier selection by setting "openid.identity" to "http://specs.openid.net/auth/2.0/identifier_select" and there are Identifiers for which the end user is authorized to issue authentication responses, the OP SHOULD allow the end user to choose which Identifier to use.
If the Relying Party supplied an association handle with the authentication request, the OP SHOULD attempt to look up an association based on that handle. If the association is missing or expired, the OP SHOULD send the "openid.invalidate_handle" parameter as part of the response with the value of the request's "openid.assoc_handle" parameter, and SHOULD proceed as if no association handle was specified.
If no association handle is specified, the OP SHOULD use a private association for signing the response. The OP MUST store this association and MUST respond to later requests to check the signature of the response via Direct Verification (Verifying Directly with the OpenID Provider).
Relying Parties SHOULD accept and verify assertions about Identifiers for which they have not requested authentication. OPs SHOULD use private associations for signing unsolicited positive assertions.
If the "openid.return_to" value is omitted in the request, the Relying Party does not wish to receive an authentication assertion from the OP. This can be useful when using extensions to transfer data from the Relying Party to the OP.
| TOC |
Positive assertions are indirect responses (Indirect Communication) with the following fields:
As specified in Section 4.1.2 (HTTP Encoding).
Value: "id_res"
The OP Endpoint URL.
Value: (optional) The Claimed Identifier. "openid.claimed_id" and "openid.identity" SHALL be either both present or both absent.
Note: The end user MAY choose to use an OP-Local Identifier as a Claimed Identifier.
Note: If neither Identifier is present in the assertion, it is not about an identifier, and will contain other information in its payload, using extensions (Extensions).
Value: (optional) The OP-Local Identifier
Note: OpenID Providers MAY assist the end user in selecting the Claimed and OP-Local Identifiers about which the assertion is made. The openid.identity field MAY be omitted if an extension is in use that makes the response meaningful without it (see openid.claimed_id above).
Value: Verbatim copy of the return_to URL parameter sent in the request.
Value: A string 255 characters or less in length, that MUST be unique to this particular successful authentication response. The nonce MUST start with the current time on the server, and MAY contain additional ASCII characters in the range 33-126 inclusive (printable non-whitespace characters), as necessary to make each response unique. The date and time MUST be formatted as specified in section 5.6 of [RFC3339] (Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps,” .), with the following restrictions:
For example: 2005-05-15T17:11:51ZUNIQUE
- All times must be in the UTC timezone, indicated with a "Z".
- No fractional seconds are allowed
Value: (optional) If the Relying Party sent an invalid association handle with the request, it SHOULD be included here.
Value: The handle for the association that was used to sign this assertion.
Value: Comma-separated list of signed fields.
Note: This entry consists of the fields without the "openid." prefix that the signature covers. This list MUST contain at least "op_endpoint", "return_to" "response_nonce" and "assoc_handle", and if present in the response, "claimed_id" and "identity". Additional keys MAY be signed as part of the message. See Generating Signatures (Generating Signatures).
For example, "op_endpoint,identity,claimed_id,return_to,assoc_handle,response_nonce".
Value: Base 64 encoded signature calculated as specified in Section 6 (Generating Signatures).
| TOC |
If the OP is unable to identify the end user or the end user does not or cannot approve the authentication request, the OP SHOULD send a negative assertion to the Relying Party as an indirect response (Indirect Communication).
When receiving a negative assertion in response to a "checkid_immediate" mode request, Relying Parties SHOULD construct a new authentication request using "checkid_setup" mode. Details about how this differs from OpenID Authentication 1.1 can be found in Section 14 (OpenID Authentication 1.1 Compatibility).
| TOC |
If the request was an immediate request, there is no chance for the end user to interact with pages on the OP to provide identifying credentials or approval of a request. A negative assertion of an immediate request takes the following form:
As specified in Section 4.1.2 (HTTP Encoding).
Value: "setup_needed"
| TOC |
Since the OP may display pages to the end user and request credentials from the end user, a negative response to a request that is not immediate is definitive. It takes the following form:
As specified in Section 4.1.2 (HTTP Encoding).
Value: "cancel"
Often, if the user does not wish to or cannot complete the authentication request, the OpenID authentication process will be aborted and the Relying Party will not get a cancel mode response (the end user may quit or press the back button in their User-Agent instead of continuing). If a RP receives the "cancel" response, authentication was unsuccessful and the RP MUST treat the end user as non-authenticated.
| TOC |
When the Relying Party receives a positive assertion, it MUST verify the following before accepting the assertion:
If all four of these conditions are met, assertion is now verified. If the assertion contained a Claimed Identifier, the user is now authenticated with that identifier.
| TOC |
To verify that the "openid.return_to" URL matches the URL that is processing this assertion:
| TOC |
If the Claimed Identifier in the assertion is a URL and contains a fragment, the fragment part and the fragment delimiter character "#" MUST NOT be used for the purposes of verifying the discovered information.
If the Claimed Identifier is included in the assertion, it MUST have been discovered (Discovery) by the Relying Party and the information in the assertion MUST be present in the discovered information. The Claimed Identifier MUST NOT be an OP Identifier.
If the Claimed Identifier was not previously discovered by the Relying Party (the "openid.identity" in the request was "http://specs.openid.net/auth/2.0/identifier_select" or a different Identifier, or if the OP is sending an unsolicited positive assertion), the Relying Party MUST perform discovery on the Claimed Identifier in the response to make sure that the OP is authorized to make assertions about the Claimed Identifier.
If no Claimed Identifier is present in the response, the assertion is not about an identifier and the RP MUST NOT use the User-supplied Identifier associated with the current OpenID authentication transaction to identify the user. Extension information in the assertion MAY still be used.
| Discovered Value | Response Field |
|---|---|
| Claimed Identifier | openid.claimed_id |
| OP-Local Identifier | openid.identity |
| OP Endpoint URL | openid.op_endpoint |
| Protocol Version | openid.ns |
This table shows the mapping of discovered information (Discovered Information) into fields in the OpenID Authentication 2.0 "id_res" response (Positive Assertions)
| Discovered Information to Authentication Response Mapping |
If using a discovery mechanism that yields an XRDS document, the protocol version, OP Endpoint URL and the OP-Local Identifier (if different than the Claimed Identifier) MUST be present in one <xrd:Service> element. There MAY be unused fields in that <xrd:Service> element.
Non-normative example:
<Service xmlns="xri://$xrd*($v*2.0)"> <Type>http://specs.openid.net/auth/2.0/signon</Type> <URI>http://provider.example.com/openid</URI> <URI>https://provider.example.com/openid</URI> </Service>
In this example XRDS snippet, the <xrd:Service> element has two <xrd:URI> elements, which map to OP Endpoint URLs as per Section 7.3.1 (Discovered Information). If an assertion has either value for "openid.op_endpoint", then that field matches this <xrd:Service> element. The other <xrd:URI> element is unused.
| TOC |
To prevent replay attacks, the agent checking the signature keeps track of the nonce values included in positive assertions and never accepts the same value more than once for the same OP Endpoint URL.
The time-stamp MAY be used to reject responses that are too far away from the current time, limiting the amount of time that nonces must be stored to prevent attacks. The acceptable range is out of the scope of this specification. A larger range requires storing more nonces for a longer time. A shorter range increases the chance that clock-skew and transaction time will cause a spurious rejection.
| TOC |
If the Relying Party has stored an association with the association handle specified in the assertion, it MUST check the signature on the assertion itself. If it does not have an association stored, it MUST request that the OP verify the signature via Direct Verification (Verifying Directly with the OpenID Provider).
| TOC |
The Relying Party follows the same procedure that the OP followed in generating the signature (Generating Signatures), and then compares the signature in the response to the signature it generated. If the signatures do not match, the assertion is invalid.
If an authentication request included an association handle for an association between the OP and the Relying party, and the OP no longer wishes to use that handle (because it has expired or the secret has been compromised, for instance), the OP will send a response that must be verified directly with the OP, as specified in Section 11.4.2 (Verifying Directly with the OpenID Provider). In that instance, the OP will include the field "openid.invalidate_handle" set to the association handle that the Relying Party included with the original request.
| TOC |
To have the signature verification performed by the OP, the Relying Party sends a direct request (Direct Request) to the OP. To verify the signature, the OP uses a private association that was generated when it issued the positive assertion (Positive Assertions).
| TOC |
Value: "check_authentication"
For verifying signatures an OP MUST only use private associations and MUST NOT use associations that have shared keys. If the verification request contains a handle for a shared association, it means the Relying Party no longer knows the shared secret, or an entity other than the RP (e.g. an attacker) has established this association with the OP.
To prevent replay attacks, the OP MUST NOT issue more than one verification response for each authentication response it had previously issued. An authentication response and its matching verification request may be identified by their "openid.response_nonce" values.
| TOC |
As specified in Section 5.1.2 (Direct Response).
Value: "true" or "false"; asserts whether the signature of the verification request is valid.
Value: (optional) The "invalidate_handle" value sent in the verification request, if the OP confirms it is invalid.
Description: If present in a verification response with "is_valid" set to "true", the Relying Party SHOULD remove the corresponding association from its store and SHOULD NOT send further authentication requests with this handle.
Note: This two-step process for invalidating associations is necessary to prevent an attacker from invalidating an association at will by adding "invalidate_handle" parameters to an authentication response.
| TOC |
The Claimed Identifier in a successful authentication response SHOULD be used by the Relying Party as a key for local storage of information about the user. The Claimed Identifier MAY be used as a user-visible Identifier. When displaying URL Identifiers, the fragment MAY be omitted.
| TOC |
OpenID Providers with large user bases can use fragments to recycle URL Identifiers if it is so desired. When reassigning a URL Identifier to a new end user OPs should generate a new, unique fragment part.
The full URL with the fragment part constitutes the Claimed Identifier in positive assertions, therefore Relying Parties will distinguish between the current and previous owners of the fragment-less URL.
This mechanism allows the (presumably short, memorable) recycled URL Identifiers without the fragment to be used by end users at login time and by Relying Parties for display purposes.
| TOC |
Relying Parties MUST differentiate between URL Identifiers that have different schemes. When end user input is processed into a URL, it is processed into a HTTP URL. If the same end user controls the same URL, differing only by scheme, and it is desired that the Identifier be the HTTPS URL, it is RECOMMENDED that a redirect be issued from the HTTP URL to the HTTPS URL. Because the HTTP and HTTPS URLs are not equivalent and the Identifier that is used is the URL after following redirects, there is no foreseen reduction in security when using this scheme. If an attacker could gain control of the HTTP URL, it would have no effect on the HTTPS URL, since the HTTP URL is not ever used as an Identifier except to initiate the discovery process.
| TOC |
An Extension to OpenID Authentication is a protocol that "piggybacks" on the authentication request and response. Extensions are useful for providing extra information about an authentication request or response as well as providing extra information about the subject of the authentication response.
OpenID extensions are identified by a Type URI. The Type URI MAY be used as the value of an <xrd:Type> element of an OpenID <xrd:Service> element in an XRDS document associated with a Claimed Identifier. The Type URI is also used to associate key-value pairs in messages with the extension.
To associate keys and values in a message with an extension, the key MUST be associated with the Type URI. To associate keys with a Type URI, establish an alias by adding a key prefixed with "openid.ns." and ending with the alias text whose value is the Type URI. Once an alias has been established, all pairs in the message whose keys start with "openid." followed by the alias text, followed by a period or the end of the key are associated with that extension. This mechanism is similar to the XML namespaces.
A namespace alias MUST NOT contain a period and MUST NOT be the same as another namespace alias in the same message. A namespace alias also MUST NOT be in the following list of disallowed aliases:
A namespace MUST NOT be assigned more than one alias in the same message. If a message is a response to another message, the response MAY use a different alias to refer to the same namespace.
Non-normative example:
An extension's type URI is "<http://example.com/ext/1.0>".
openid.ns.x=http://example.com/ext/1.0
openid.x=example
openid.x.foo=bar
openid.xx=notx
In this example, the keys "openid.x" and "openid.x.foo" are associated with the extension; the "openid.xx" key is not.
Extensions MUST NOT define multiple parameters with the same name. Extensions that need to send multiple values for the same parameter name must define their own conventions for doing so.
| TOC |
Relying Party discovery allows for software agents to discover sites that support OpenID. It also allows OpenID providers to automatically verify that a return_to URL in an OpenID request is an OpenID relying party endpoint for the specified realm.
Relying Parties SHOULD use the Yadis protocol to publish their valid return_to URLs. The relying party MAY publish this information at any URL, and SHOULD publish it under the realm so that providers can verify return_to URLs.
A Relying Party discovery XRDS document MUST contain one or more <xrd:Service> elements:
Non-normative example:
<Service xmlns="xri://$xrd*($v*2.0)"> <Type>http://specs.openid.net/auth/2.0/return_to</Type> <URI>http://consumer.example.com/return</URI> </Service>
| TOC |
This section describes how to interact with OpenID Authentication 1.1 Relying Parties and OPs. OpenID Authentication 2.0 implementations SHOULD support OpenID Authentication 1.1 compatibility, unless security considerations make it undesirable.
| TOC |
(non-normative)
This specification is based on the original specification for OpenID Authentication as written by Brad Fitzpatrick. That specification did not have a version number, but was called OpenID 1.0, and then OpenID 1.1 when it was revised. The protocol outlined in this specification is intended to be backwards-compatible with the revised OpenID protocol. The changes to the specification are outlined in this section.
| TOC |
| TOC |
A nonce is now part of the protocol for built-in protection against replay attacks, which was previously implemented out-of-band by each library or application.
A new association type, HMAC-SHA256, and a new association session type, DH-SHA256, allow for stronger signatures on authentication assertions.
An actual Security Considerations section (Security Considerations) which looks at protecting the protocol from end-to-end.
| TOC |
Extensions are now an officially supported mechanism to support data exchange and other Relying Party-OP communication along with the authentication exchange. Extensions allow for the exchange of arbitrary attributes, as well as for protocol extensions, such as the inclusion of additional information about the Relying Party in the authentication request.
Because extensions can transfer arbitrary data, the Identifier is now optional in authentication messages.
| TOC |
All messages in OpenID Authentication 1.1 omit the "openid.ns" parameter, which is an easy way for an RP to determine if the message is from an OpenID Authentication 1.1 endpoint. OpenID Authentication 1.1 supports only HMAC-SHA1 associations.
Error responses in OpenID Authentication 1.1 did not define "contact" or "reference". OpenID Authentication 1.1 did allow for the addition of extra fields in error responses. It is RECOMMENDED for contact and reference to be sent even when using OpenID Authentication 1.1, since they may be useful for debugging and do not affect compatibility.
| TOC |
| TOC |
| TOC |
| TOC |
| TOC |
There is one place in this protocol that is vulnerable to eavesdropping attacks.
This attack can be prevented by using transport layer encryption for these connections to prevent eavesdropping. In addition, if not using TLS this attack can still be prevented by checking the nonce while performing message verification. When doing so, the positive authentication assertion cannot be re-used.
| TOC |
Associations prevent tampering of signed fields by a man in the middle except during discovery, association sessions and Direct Verification (Verifying Directly with the OpenID Provider). Altering signed fields without the shared secret requires breaking the MAC. Currently no tractable attack is known on the MACs used in this protocol. The quality of the protection provided by the MAC depends on the randomness of the shared MAC key, so it is important that an unguessable value be used.
If DNS resolution or the transport layer is compromised signatures on messages are not adequate, since the attacker can impersonate the OP and issue its own associations, or its own decisions in Stateless Mode. If an attacker can tamper with the discovery process they can specify any OP, and so does not have to impersonate the OP. Additionally, if an attacker can compromise the integrity of the information returned during the discovery process, by altering the XRDS document, the need for a man in the middle is removed. One method to prevent this sort of attack is by digitally signing the XRDS file as per XMLDSIG (Eastlake 3rd, D., Reagle Jr., J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing,” .) [RFC3275]. The keying material is not specified, since the RP ultimately needs to make its own decision whether to trust keys used for such signature.
Using SSL with certificates signed by a trusted authority prevents these kinds of attacks by verifying the results of the DNS look-up against the certificate. Once the validity of the certificate has been established, tampering is not possible. Impersonating an SSL server requires forging or stealing a certificate, which is significantly harder than the network based attacks.
In order to get protection from SSL, SSL must be used for all parts of the interaction, including interaction with the end user through the User-Agent. While the protocol does not require SSL be used, its use is strongly RECOMMENDED. Current best practices dictate that an OP SHOULD use SSL, with a certificate signed by a trusted authority, to secure its Endpoint URL as well as the interactions with the end user's User-Agent. In addition, SSL, with a certificate signed by a trusted authority, SHOULD be used so that a Relying Party can fetch the end user's URL in a secure manner. Following its own security policies, a Relying Party MAY choose to not complete, or even begin, a transaction if SSL is not being correctly used at these various endpoints.
| TOC |
A special type of man-in-the-middle attack is one where the Relying Party is a rogue party acting as a MITM. The RP would perform discovery on the End User's Claimed Identifier and instead of redirecting the User Agent to the OP, would instead proxy the OP through itself. This would thus allow the RP to capture credentials the End User provides to the OP. While there are multiple ways to prevent this sort of attack, the specifics are outside the scope of this document. Each method of prevention requires that the OP establish a secure channel with the End User.
| TOC |
Since this protocol is intended to be used interactively, User-Agents will primarily be common Web browsers. Web browsers or their hosts may be infected with spyware or other malware, which limits the strength of the authentication assertion, since untrusted software makes it impossible to know whether the authentication decision has been made with the end user's approval. With that said, many web applications and protocols today rely on the security of the Web browser and their hosts.
Cross-site-scripting attacks against OPs may be used to the same effect. For the best security, OPs should not depend on scripting. This enables User-Agents that do not support scripting, or have scripting disabled, to still employ the protocol.
| TOC |
The Relying Party SHOULD redirect the end user to the OP Endpoint URL in a top-level browser window with all controls visible. This allows better protection for the end user against OP look-alike sites (phishing).
OpenID Providers SHOULD educate their end users about the potential for OpenID phishing attacks and SHOULD equip their end users with the tools to defeat such attacks, for example browser plug-ins that verify the authenticity of the OP's Authentication Service Endpoint URL.
| TOC |
While these types of Identifiers have been previously discussed (HTTP and HTTPS URL Identifiers), they are worth mentioning again. As previously stated, the RECOMMENDED method of an End User expressing control over a URL differing only be scheme is to setup a redirect from the HTTP URL to the HTTPS URL. Relying Parties will never store the HTTP URL as during the discovery and initiation phase will follow the redirect and use the HTTPS URL as the Claimed Identifier.
End users with concerns over this recommendation should directly enter their HTTPS URL at each Relying Party. This thus removes the step where the Relying Party follows the redirect to the HTTPS URL. The single security consideration currently seen is if an attacker were to compromise the integrity of the HTTP URL by removing the redirect and pointing the Identifier at a rogue OP. This however will alter the user experience, is detectable by anti-phishing technologies, and the security of the Identifier itself is a fundamental principle within OpenID.
| TOC |
Within the protocol there are places where a rogue RP could launch a denial of service attack against an OP since there is nothing in OpenID protocol messages that allows the OP to quickly check that it is a genuine request. This can be done by the RP repeatedly requesting associations, authentication, or verification of a signature.
The potentially most severe attack is during the association phase as each message requires the OP to execute a discrete exponentiation. Since the RP has the ability to specify modulus and generator per message, an attacker can even force the OP to perform this exponentiation in real time prior to responding for each message.
While this could be particularly harmful, OpenID Providers can easily use generic IP based rate-limiting and banning techniques to help combat these sorts of attacks. OPs can also look at banning requests based on the "openid.realm" and "openid.return_to" values.
| TOC |
The following are known variations in the protocol which may or may not directly affect the security of the use of the protocol. It is imagined that these values could be used in the creation of security profiles for this protocol. The following list of variants are from the perspective of an OpenID Provider.
| Number | Variant | Values |
|---|---|---|
| 1. | Are wildcards allowed in realms? | One of Yes/No |
| 2. | Require prior association? Does the OP require the RP first create an association before requesting authentication? | One of Yes/No |
| 3. | Types of claimed identifiers accepted. | Set of HTTP/HTTPS/XRI |
| 4. | Are self-issued certificates allowed for authentication? This applies to all SSL traffic. If 'no' here, then OP *probably* requires all HTTPS identifiers to chain up to known trust roots, but that's intentionally not implied. | One of Yes/No |
| 5. | Must the XRDS file be signed? Signature on the XRDS as per XMLDSIG. Keying material not specified, since the RP ultimately needs to make own decision whether to trust keys used for such signature. | One of Yes/No |
| 6. | Must the XRDS file be retrieved over secure channel? This does not imply SSL? | One of Yes/No |
| 7. | What types of session types can be used when creating associations? | Set of no-encryption/DH-SHA1/DH-SHA256 |
| 8. | Must the RP have an XRDS document? | One of Yes/No |
| 9. | What association types the OP agrees to use for signatures? | Set of HMAC-SHA1/HMAC-SHA256 |
| 10. | Must the association request take place over secure channel? | One of Yes/No |
Identified security variants.
| TOC |
Non-normative
| TOC |
See section 6 of [RFC3986] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) for textual URL normalization details and more examples.
| User's Input | Identifier | Type | Discussion |
|---|---|---|---|
| example.com | http://example.com/ | URL | A URI with a missing scheme is normalized to a http URI |
| http://example.com | http://example.com/ | URL | An empty path component is normalized to a slash |
| https://example.com/ | https://example.com/ | URL | https URIs remain https URIs |
| http://example.com/user | http://example.com/user | URL | No trailing slash is added to non-empty path components |
| http://example.com/user/ | http://example.com/user/ | URL | Trailing slashes are preserved on non-empty path components |
| http://example.com/ | http://example.com/ | URL | Trailing slashes are preserved when the path is empty |
| =example | =example | XRI | Normalized XRIs start with a global context symbol |
| xri://=example | =example | XRI | Normalized XRIs start with a global context symbol |
| User's Input to Identifier Normalization |
| TOC |
An end user wants to use "http://www.example.com/" as their Claimed Identifier. The end user has an account with Example Provider, which functions as an OpenID Provider. The end user's OP-Local Identifier is "https://exampleuser.exampleprovider.com/".
In this scenario, with the proper configuration of Yadis or HTML-Based Discovery (see Section 7.3 (Discovery) and Appendix A.3 (XRDS) below), a Relying Party will discover the following information about the end user:
- Claimed Identifier
- http://www.example.com/
- OP-Local Identifier
- https://exampleuser.exampleprovider.com/
| TOC |
For an end user to use "http://www.example.com/" as their Identifier, but have Relying Parties actually verify "https://exampleuser.exampleprovider.com/" with the OP Endpoint URL "https://www.exampleprovider.com/endpoint/", the following XML snippet should be present in the final XRD element in the XRDS file when discovery is preformed on "http://www.example.com/":
<Service xmlns="xri://$xrd*($v*2.0)"> <Type>http://specs.openid.net/auth/2.0/signon</Type> <URI>https://www.exampleprovider.com/endpoint/</URI> <LocalID>https://exampleuser.exampleprovider.com/</LocalID> </Service>
| TOC |
To use "http://www.example.com/" as their Identifier, but have Relying Parties actually verify "http://exampleuser.livejournal.com/" with the OpenID Provider located at "http://www.livejournal.com/openid/server.bml", the following markup should be present in the <head> of the HTML document located by the identifier URL:
<link rel="openid2.provider openid.server" href="http://www.livejournal.com/openid/server.bml"/> <link rel="openid2.local_id openid.delegate" href="http://exampleuser.livejournal.com/"/>
| TOC |
For example, if the XRI i-names =example and =exmpl both yield an XRDS document with the CanonicalID xri://(example)!1234 then those Identifiers should be treated as equivalent. For applications with user accounts, the persistent Canonical ID xri://(example)!1234 should be used the primary key for the account. Although the i-names =example and =exmpl may also be stored for reference as display names, they are reassignable identifiers and should not be used as persistent keys.
| TOC |
This is a confirmed-prime number, used as the default modulus for Diffie-Hellman Key Exchange. In hexadecimal:
DCF93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7623731866E61E F75A2E27898B057F9891C2E27A639C3F29B60814581CD3B2CA3986D268370557 7D45C2E7E52DC81C7A171876E5CEA74B1448BFDFAF18828EFD2519F14E45E382 6634AF1949E5B535CC829A483B8A76223E5D490A257F05BDFF16F2FB22C583AB
| TOC |
The OpenID Community would like to thank the following people for the work they've done in the drafting and editing of this specification. If you want to know the nitty gritty of who actually wrote what, feel free to look at our SVN repository or even use "svn blame". :) http://openid.net/svn/specifications/authentication/2.0/
Barry Ferg<EMAIL_ADDRESS>Brad Fitzpatrick<EMAIL_ADDRESS><author>
Carl Howells<EMAIL_ADDRESS>David Recordon<EMAIL_ADDRESS><author/editor>
Dick Hardt<EMAIL_ADDRESS><author>
Drummond Reed<EMAIL_ADDRESS>Hans Granqvist<EMAIL_ADDRESS>Johannes Ernst<EMAIL_ADDRESS>Johnny Bufu<EMAIL_ADDRESS><editor>
Josh Hoyt<EMAIL_ADDRESS><author/editor>
Kevin Turner<EMAIL_ADDRESS>Marius Scurtescu<EMAIL_ADDRESS>Martin Atkins<EMAIL_ADDRESS>Mike Glover<EMAIL_ADDRESS>| TOC |
| TOC |
|<EMAIL_ADDRESS>|


Leo Santa Cruz wins title in fourth division with unanimous decision
by Dan RafaelLAS VEGAS -- When Leo Santa Cruz began as a professional boxer, his goal was to win a world title. But once he accomplished that, he wanted to win one in another division. And when he accomplished that, he went for one in a third weight class.
When the opportunity to win a title in a fourth division was presented to him, Santa Cruz happily accepted the challenge and cruised to a unanimous decision over fellow Mexico native Miguel Flores to claim a vacant junior lightweight belt in the Deontay Wilder-Luis Ortiz II co-feature on Saturday night at the MGM Grand Garden Arena.
The judges scored the fight 117-110, 117-110 and 115-112. ESPN had it 119-109 for Santa Cruz.
| Punches | Santa Cruz | Flores |
|---|---|---|
| Total landed | 253 | 222 |
| Total thrown | 907 | 1024 |
| Percent | 28% | 22% |
| Jabs landed | 42 | 8 |
| Jabs thrown | 374 | 196 |
| Percent | 11% | 4% |
| Power landed | 211 | 214 |
| Power thrown | 533 | 828 |
| Percent | 40% | 26% |
| -- Courtesy of CompuBox |
Santa Cruz (37-1-1, 19 KOs), 31, of Rosemead, California, who has also won world titles at bantamweight, junior featherweight and featherweight, became the fifth Mexican boxer to win a world title in four weight classes. He joined Hall of Famer Erik Morales, Juan Manuel Marquez and Jorge Arce, both of whom are on this year's ballot for the first time, and Canelo Alvarez, who accomplished it on Nov. 2 when he knocked out Sergey Kovalev to win a light heavyweight title.
"Winning this title means the world to me. This is all for the fans who support me," Santa Cruz said. "I didn't feel myself today and didn't perform the way I wanted to.  I'm glad I got the victory. Miguel is a good fighter, he gave me a tough fight and he proved he's not a pushover."
Santa Cruz was supposed to defend his featherweight belt against Flores on Feb. 16 in Los Angeles, but Flores suffered an ankle injury and withdrew, and Santa Cruz instead outpointed Rafael Rivera in a one-sided fight. But then the fight was made again at the heavier weight.
Santa Cruz was a bit less active than he usually is, but he landed a nice right hand that stunned Flores in the third round and steadily put his punches together. He maintained control throughout the fight against Flores (24-3, 12 KOs), 27, of Houston, who was a heavy underdog.
Santa Cruz forced Flores back with long left hands and also mixed in some body shots in the lackluster fight. They had promised to steal the show but instead made for an entirely forgettable match whose biggest cheers came when Mike Tyson entered the arena during the eighth round.
Later in the eighth round, referee Tony Weeks penalized Flores one point for holding.
"I just went 12 rounds with Leo Santa Cruz. It's not an accomplishment in itself, but I slowed down his pace," Flores said. "It was a close fight and I didn't think he was landing too much. He was busy, but he wasn't landing too many shots. I landed cleaner harder shots. I want to go back down to 126 pounds."
Santa Cruz still holds a featherweight title but said he planned to stay at junior lightweight and called out big names.
"I want to stay at 130. We want the big fights in 2020," he said. "I want Gervonta Davis or Gary Russell Jr. I want to show the world I'm not scared of anybody."
Figueroa and Ceja battle to draw
In a very grueling and action-packed fight, secondary junior featherweight world titlist Brandon Figueroa and Julio Ceja battled to a split decision draw. One judge had it 115-113 for Figueroa, one had it 116-112 for Ceja and one had it 114-114. ESPN also had it 114-114.
| Punches | Figueroa | Ceja |
|---|---|---|
| Total landed | 411 | 373 |
| Total thrown | 1338 | 1473 |
| Percent | 31% | 25% |
| Jabs landed | 39 | 6 |
| Jabs thrown | 506 | 95 |
| Percent | 8% | 6% |
| Power landed | 372 | 367 |
| Power thrown | 832 | 1378 |
| Percent | 45% | 27% |
| -- Courtesy of CompuBox |
Figueroa (20-0-1, 15 KOs), 22, of Weslaco, Texas, retained his 122-pound belt for the first time but even had he lost the fight he would have kept the title. Figueroa was on the division limit of 122 pounds at Friday's weigh-in but former world titleholder Ceja (32-4-1, 28 KOs) was dramatically overweight, coming in at 126¼ pounds, well over the division limit, so he was not eligible to win the belt.
"I think I did win the fight," Figueroa said. "He put on a lot of pressure, but I fought better in the early rounds and I finished strong. I feel like he won maybe four rounds out of the whole fight. I thought I won the first four and closed out the last few rounds of the fight strong.
"His body weight was a factor. I couldn't really move him when I hit him. He didn't have to drain himself, but we took the fight and we won't make excuses."
Figueroa, whose seven-fight knockout streak ended, started fast and had a big first round. He strafed Ceja with numerous clean shots to the head and body, particularly over the second half of the round. But Ceja got into the fight in the second round, and in the third round they mostly stood chest to chest, banging away at each other. They continued to slug at close range round after round as each landed many shots to the head and hooks to the body.
Ceja did damage in the 10th round with his left hook, including one late in the round to the head that really rocked Figueroa, who closed strong in the 12th round.
"He was a man about it and he gave me the fight. I think I won, but I respect the judges' decision. I'll definitely run it back in a rematch," Ceja said through an interpreter.
Ceja, 26, of Mexico, ended a two-fight losing skid in which he was knocked out both times, by Franklin Manzanilla in May 2018 and by former world champion Guillermo Rigondeaux on June 23.
Ramirez stops Barthelemy in rematch
Featherweight Eduardo Ramirez (23-2-3, 10 KOs) knocked out fellow southpaw Leduan Barthelemy (15-1-1, 7 KOs) in the fourth round of a rematch. They fought to a 10-round draw in September 2017.
"I said before the fight I wasn't going to let it go to the judges and that's what I did tonight," Ramirez said through an interpreter. "The first fight wasn't a draw. I worked very hard for this and it turned out how I wanted today. I felt his punching power. He's a good fighter but I came here to fight. Viva Mexico."
| Punches | Barthelemy | Ramirez |
|---|---|---|
| Total landed | 52 | 73 |
| Total thrown | 215 | 288 |
| Percent | 24% | 25% |
| Jabs landed | 16 | 5 |
| Jabs thrown | 116 | 65 |
| Percent | 14% | 8% |
| Power landed | 36 | 68 |
| Power thrown | 99 | 223 |
| Percent | 36% | 31% |
| -- Courtesy of CompuBox |
Mexico's Ramirez, 26, a former world title challenger, landed a clean left hand to the head that stunned Barthelemy in the third round. He continued to land clean shots in the fourth round and Barthelemy had no answers. Finally, Ramirez landed a hard left hand to the face that dropped Las Vegas-based Cuban defector Barthelemy, 30, the younger brother of two-division titlist Rances Barthelemy. He got up quickly but was very unsteady and referee Russell Mora stopped the fight at 2 minutes, 59 seconds.
"I've got no excuses," Barthelemy said. "The better man won tonight. I had a great camp and I was feeling good. But when I got out there I wasn't really feeling my best."
On Friday, the fight was moved up the card to open the pay-per-view telecast because the bantamweight title elimination fight between former world titleholders Luis Nery and Emmanuel Rodriguez was canceled at the weigh-in when Nery was 119 pounds, one over the limit, and Rodriguez declined to make a financial deal for the fight to go ahead.
Juarez dominates Shacks
Junior welterweight prospect Omar Juarez (6-0, 3 KOs), 20, of Brownsville, Texas, knocked out Kevin Shacks (3-5-3, 3 KOs), 29, of Lansing, Michigan, in the sixth round of a one-sided fight.
Juarez nearly ended the fight in the first round in which he scored two knockdowns and landed several thunderous punches. He dropped Shacks with a left hook to the body and later with a left to the head. In the sixth round, he dropped Shacks to all fours with a right hand, and referee Vic Drakulich counted him out at 1 minute, 59 seconds.
Mielnicki stops Bailey in second round
Welterweight Vito Mielnicki Jr. (3-0, 3 KOs), a 17-year-old from Roseland, New Jersey, who had to get a special permit to box in Nevada because of his age, knocked out Marklin Bailey (6-6, 4 KOs), 25, of Durham, North Carolina, in the second round.
Mielnicki rocked him with a left hook-right hand combination and followed with a series of punches that again hurt Bailey, who is trained by former women's boxing star Christy Martin. A right hand then sent Bailey into the ropes, and referee Russell Mora stopped it at 2 minutes, 31 seconds.
Long drills M. Wilder
Cruiserweight Dustin Long (3-1-2, 3 KOs) scored a sensational one-punch, fourth-round knockout against Marsellos Wilder (5-2, 2 KOs) offrom Tuscaloosa, Alabama, who is Deontay Wilder's 30-year-old younger brother.
There was very little action in the fight through the first three rounds, but it ended explosively when Long, 37, of Johnson City, Tennessee, crushed Wilder with a left hand square on the chin that dropped him hard, flat on his back. Wilder hit his head on the canvas and referee Jay Nady immediately stopped the fight without a count at 1 minute, 51 seconds.
Slavinskyi outpoints Hermosillo
Los Angeles-based Ukrainian junior lightweight Viktor Slavinskyi (11-0-1, 6 KOs), who is trained by Jose Santa Cruz (Leo Santa Cruz's father), outfought Rigoberto Hermosillo (11-2-1, 8 KOs), 27, of Mexico, to win a unanimous decision. The judges had it 60-54, 59-55 and 58-56.
It was a rough, physical fight in which the fighters exchanged various fouls. Slavinskyi suffered a cut over his right eye in the fourth round. It appeared to be from an accidental head butt. Hermosillo lost his second decision in a row.
Alejandro outpoints Yap
Featherweight Angel Alejandro (8-0 4 KOs), 19, of Dallas, won a unanimous decision against Mark John Yap (30-15, 15 KOs), 30, of the Philippines, who gave a him a solid test. In the end, Alejandro, whose older brother Arnold lost his undefeated record in the previous fight, was 58-56 on two scorecards and 59-55 on the third. Both Alejandro brothers are part of Mikey Garcia's promotional company.
Gemino flattens Alejandro
Lightweight Jhon Gemino (21-12-1, 11 KOs), 27, of the Philippines, scored an upset as he knocked out Arnold Alejandro (11-1, 10 KOs), 23, of Dallas in highlight-reel fashion in the third round.
Gemino, who was coming off a second-round, knockout loss in July, dropped Alejandro with a left hand and nearly stopped him in the first round. In the fifth round of their scheduled eight-rounder, Gemino dropped Alejandro flat on his back with a right hand on the chin, and referee Robert Byrd waved it off at 1 minute, 45 seconds.
Gomez drops Placeres three times
Junior lightweight Jose Manuel Gomez (12-0, 5 KOs), 23, of Huntington Park, California, easily disposed of Daniel Placeres (8-3-1, 7 KOs), 31, of Miami, stopping him at the end of the third round of their scheduled eight-round fight.
Gomez knocked down Placeres three times, once in each round, before Placeres' corner threw in the towel at the end of third round.


I'm a student at the University of Texas at Austin studying Computer Science.
Projects
Cat Viewer
Android app that displays cat images from Imgur.
MakeRoute
A dynamic web application that utilizes the power of the Google Maps and Yelp APIs to bring you the top rated travel destinations that you would otherwise just be passing by.
Our HackDFW 2015 project.
Timer
Pomodoro Timer for Android.


The This Morning star stepped away from the sofa to soak up the festivities in the capital.
Wrapped up warm for the night out, Holly wore a roll-neck top, a belted black coat and a wine-coloured knitted hat.
Harry, ten, Belle, eight, and Chester, five, were also protected from the elements, all wearing bobble hats, coats and gloves.
Read more: Zoe Ball apologises as SCD It Takes Two is forced off air due to technical issues
Holly shared a picture of the trio walking through a Christmas market towards Winter Wonderland's fun fair rides.
She said: "Thank you for a dreamy night @hydeparkwinterwonderland."
With hardly anyone else in the picture, Holly's followers wondered if they had "closed the place for you".
"No crowds?!! You lucky thing!!!" said one follower.
Read more: I'm A Celebrity viewers are all making the same joke after Nadine's shock confession
"Did they close the place down for you?" asked another.
"How did you get in early?" quizzed another.
"Erm, because she's Holly Willoughby," came another fan's reply.
Indeed, as the fan suggested, Holly was attending the attraction's VIP launch, with TOWIE star Gemma Collins also enjoying the festive night out.
Let us know what you think of our story on our Facebook page @EntertainmentDailyFix.


| DOSE: T+ 0:00 |
23 mg |
oral |
2C-B |
| T+ 2:30 |
1 bump |
insufflated |
Ketamine |
| T+ 6:20 |
10 mg |
insufflated |
2C-B |
| T+ 6:20 |
1 bump |
insufflated |
Ketamine |
| T+ 9:00 |
10 mg |
insufflated |
2C-B |
| T+ 9:00 |
1 bump |
insufflated |
Ketamine |
Prior in the day to this experience i wondered about the effects of combining 2cb(snorted) and ketamine and thought best to stay away or at least do some research first. unfortunatley the internet was not accessible, and now finding out there are no reports included on this combination i thought i would have to contribte. so here we go...
9.00pm - i measure out two 23mg hits of 2cb for me and friend A. Friend B then weighs out two 25mg hits for himself and friend C. we eat them up rapidly at this time.
we head off to a techno club about 10 or so and by 10.30 am begining to feel the effects. A doesnt seem to be feeling half as high as me (he hasnt taken the substance before so may not recognise its onset) and for B things seem to be rising fast.
11.30? we decide to intensify the already enjoyable and trippy high by snorting some K. im not tosure how much the others took but i had a rather fat coin and within minutes was begining to feel the familiar onset of K. but in the beautiful 2cb colours. C doesnt take any K for now. but B PROBABLY snorted more than me and A who has never had K before either PROBABLY had less.
for the next half an hour i was lost in a lovely world quite unable to stand but thouroughly enjoying it all. we leave the club and head to another place to see some friends - by now (2am?) the K is well gone but am still high from 2cb. We leave the next venue about 3am and head back to B and Cs home.
On arrival we all inhale 10mg of 2cb and a good line of K about 2 mins later(by now 3.20am or so). 10 mins later we are all incredibly ruined . the visuals were phenomenal and we listened to really loud hard techno for a while whilst generally laughing around and getting lost in our selves. my sense of time totally went by this point and im unsure of times exactly from this point.
as we started to come down from the previous lines - roughly 5am? - but still incredibly tripped out i proceed to round 2
B requests a line of solely K so i rack him one up that was quite large but we had quite a disagreement about heavy it would be - with me stupidly sayin i would of snorted 2x the amount on a sober head and then B tryin to make me do just that - to no avail. but feeling that 2cb is much more appropriate to be doing i put a sly 3mg into his line. A and C both get a smaller line of K with about 3-4mg of 2cb in as well.
I decide on 10mg and a smallish amount of K - not enough to normally get me into its digital domain.
within a minute of snorting this line im in another world - i remember the room was constantly changing it took on an infinite number of variations throughout the experience. B started playing a Johnny Cash tune and was messing with it somehow using a computer( i still dont know how he did it) and it started to sound like psychedelic folk or rock then it started to sound like reggae then like minimal techno (i was convinced it was different songs) then the whole thing climaxed in a high pitched wooooooooooooooop sound that i was completely attached to - when it ended i was incredibly disappointed. then when asked B told us that the whole thing had been Cash, the other 3 of us were amazed.
some time after snorting the line (15 mins i recon) the K began to take a hold. i felt as if i was gonna lose it. NB i have never k-holed despite countless experiences on K although ive come close before. - i got a weird sort of tunnel vision where the whole room was compressed into an incredibly small space but was still incredibly 2cb orientated. i remember waving as i thought i was gonna go and seeing incredibly intense tracers.
a few minutes later i realised i would stay with it but i was in a completely new head space - the room (visually) was a complete mix of the two drugs. it felt like a cross roads and very similar to what i experience with salvia divinorum - although i often find K and salvia have similarities - but 2cb provided the colours that salvia often does(in my minds eye)
one of the most profound hallucinations i rememeber having was a green shape in the middle of the room sucking everything into it - it was like the centre of existence and it felt very close to me. (throughout the whole night incredible visuals were happening but most of them i cant remember now but this was the one that seemed most important)
im not sure how long this second dose of lines had me but it was daylight by the time i was starting to come down. at this point B tries to get me to do more K but it still has enough of a hold for me to know it would be a stupid idea . A and B have some more K and we just sit around laughing and smoking bud for the rest of the morning - falling asleep about 10am , although i only got back to baseline about 9am.
The whole night was incredible -one of the best drug experiences ive had and one i would do again altho i would suggest that 2cb potentiates the ketamine as it was getting me a lot more than it would normally of - i did have a high tolerance to the stuff about 1 month prior to this experience but hadnt used it since then as i was using it most days in the week and wasnt really enjoying it - i feel like it is a creepy drug as in the sense i can feel it kind of looking over my shoulder in a sinister way. this did happen during this experience but the 2cb made it more tolerable. i would be happy if i never took ketamine on its own again but i would definetly take it with 2cb again - luckily i have a nice supply of both for the moment.
alot of the night i cant remember but aside the effects of ketamines far out world the trip wasnt to heavy on the mind - unlike say acid or mushrooms. which i feel makes 2cb a great party drug or one I can take to boost my mood - unlike acid or shrooms. the lack of personal insight was a bit of a disappointment but i think this is probably a good thing as it makes it much more likely my trip will go safely - i think it would be hard to have a really bad trip on 2cb unless I really over did it.
anyway sorry about the sloppyness of this report my memories of the night are very hazy, but i can say that a combination of snorting ketamine with 2cb is thouroughly enjoyable but i would go easy on the K as it seems alot more potent when combing and isnt (again personally) as enjoyable as 2cb.
All in all this was one of the most psychedelic experiences i have ever had(but as mentioned without the ego dissolution and room for fear) and i will definetly do these two drugs in combination again but would probably increase the amount of 2cb and stay with a similar amount of K.
cheers and i hope this helps the curious
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Old San Juan is most attractive with its cobble streets lined with pastel Spanish Colonial-style houses.
Position 18°28’N, 66°07’W.
Arrival can be made at San Juan Bay Marina, Club Náutico de San Juan or Cangrejos Yacht Club.
This is the preferred option rather than yachts going to the Customs House, where the officials are busy with cruise ships and commercial vessels. They prefer to come and clear yachts at the clubs or the marina.
See main Puerto Rico clearance page for full details.
Last updated November 2014.
There is a designated anchorage, just West of the San Juan Bay Marina, in the San Antonio channel. However, large cruise ships dock on the South side of this channel and encroach into this area so there is not much room. In addition, there are also a number of resident boats on moorings. Holding in soft mud at 10 metres is only fair.
Dinghies can be left at the marina for a small daily fee.
Buses run frequently to town from the nearby bus stop. Buses also run to Plaza Las Americas, a huge shopping complex. There is a good small supermarket within walking distance of the marina.
Last updated June 2015.


Portcast Worker Multicast Example
In this example, there are three web workers. The workers compute square, cube, and the fourth power of a number. As you change the slider, the number is multicast to all three workers.
Root Page
0
In this example, there are three web workers. The workers compute square, cube, and the fourth power of a number. As you change the slider, the number is multicast to all three workers.


Our guarantee: at the lounge, we’re committed to providing you, our guest, with an exceptional experience every time you visit. Whether you’re just stopping by to check in on email over an elixir, or are here for an out-of-the-ordinary dinner, you’ll find our knowledgeable service staff pay attention to every detail. If you’re not fully satisfied have a Blueberry Bliss Elixir on us.
A spicy drink made with black tea, spices, milk and honey.
A smooth, mild blend of coffees from Mexico, Bolivia and Guatemala.
Espresso, steamed milk and chocolate syrup.
A mixture of espresso, steamed milk and milk foam.
| City | Date | Temperature | Altitude | Population | Diner Rating |
|---|---|---|---|---|---|
| Walla Walla, WA | June 15th | 75 | 1,204 ft | 29,686 | 4/5 |
| Magic City, ID | June 25th | 74 | 5,312 ft | 50 | 3/5 |
| Walla Walla, WA | June 15th | 75 | 1,204 ft | 29,686 | 4/5 |
| Magic City, ID | June 25th | 74 | 5,312 ft | 50 | 3/5 |


If you are responsible for producing, reporting, validating or playing with Incident-Based Reporting (data) in any way, you’ve come to the right place!
The NIBRS PCT allows you to automatically validate NIBRS data against the FBI’s 2019.1 NIBRS rules. The primary objective of this tool is to help you identify errors in NIBRS submissions either as part of system development or in support of regular submissions to State UCR/IBR programs or to the FBI.
The tool accepts NIBRS data in "flat file" or XML formats. Subsequent to validation, this tool will present you with a detailed list of errors. You can then save the list of errors in Excel, CSV, or PDF format, making it easy to share this information as needed.
Not to worry...we do not store any IBR data that you submit to this tool. The PCT holds onto your submission just long enough to run the validation rules and then forgets all about it.
Some important things to remember:
- The validation rules implemented by the NIBRS PCT only reflect the FBI’s NIBRS rules and do not include state-specific data elements and rules. Likewise, the NIBRS PCT cannot validate some NIBRS rules specific to the submitting agency or rules that pertain to data that the FBI may already have on file. See Tool Limitations for specific details
- The NIBRS PCT is intended to assist the user in understanding how well its data aligns with the FBI NIBRS standard version 2019.1. It is not intended to substitute for FBI NIBRS or State certification.
The NIBRS PCT is licensed under the open source Apache License, version 2.0 . The source code is available here and we welcome contributions to the codebase!
Do you have questions or just want to talk about NIBRS? Contact SEARCH at nibrs@search.org


AIR AMERICA A film review by Sandy Grossmann Copyright 1990 Sandy Grossmann
Cast: Mel Gibson, Robert Downey, Jr. Director: Robert Spottiswoode
Synopsis: Pilots watch out for each other and protect themselves from assorted bad and quasi-bad guys. If you want to miss a miss, miss this one. It's a very conservatively played story that feels discontinuous and overly edited.
Billy Covington, a young helicopter pilot who does traffic reports, loses his pilot's license because of, well, stunt flying. He's not out of work for long, though: a recruiter for Air America convinces him that excitement and money are just a half-world away in beautiful Laos. Not having anything better to do, and finding the thought of exotica fairly enticing, Billy ships out and arrives at Air America's headquarters for Laos.
A word now about Air America, 1968 style. The slogan was "Anything, anywhere, any time." (Or something similar :-)) And that's what Air America could get for you if you were a "friendly" in the Vietnam war. As you probably know--but just in case you didn't--Air America was a civilian airline run by your friends, the CIA. And it was the largest airline in the world, what with branches in South America and in most trouble spots in the world.
Gene Ryack (Mel Gibson) is one of the Air America pilots in Laos; he breaks Billy in and shows him the ropes. They talk, they fly, they get shot at, they walk through jungles, etc. Sounds like a typical buddy movie, doesn't it? It's not. In a buddy movie, two characters of (usually) dissimilar backgrounds and lifestyles and mores learn Important Lessons from each other. That doesn't happen here because the two don't interact much on that level and don't really go through important changes.
That hints at the problem with this movie: the characters don't move much from their original positions. Where's the conflict that causes a wrenching moral dilemma? That is the basis for drama, and it's just not here in sufficient quantity. As a matter of fact, this film feels disjointed, as if too much cut-and-paste occurred in a dark room.
If you're interested in finding out how and why this movie got made, read the article in this month's PREMIERE magazine (the one with Nicholson on the cover). Lots of work, lots of discomfort--including typhoons and earthquakes--and lots of thought went into this movie, but something happened during its transition from an idea to a reality. Chop-chop, let's cut out the love interest. Chop-chop, don't show so much of Gene's home life. Chop-chop, there's too much talk and not enough action.
The producer realized that a summer blockbuster has to appeal to 15-year-old boys. Isn't there some sort of law against taking an adult film and "teenaging" it? Look at the lovely structure for this film: a world-weary, distrusting pilot works for the CIA and learns to watch out for his family, ignoring the compromises he has to make every day. A young pilot who stands on principle begins working for the CIA and learns that not everything is clearly right or wrong. The young pilot pulls the world-weary pilot into a contest where the compromises are unacceptable but the consequences to his family are too threatening. That would make a good movie, don't you think?
Now. How can we screw it up? Hmmm, let's see... We'll make the world-weary pilot a real cool cookie who never worries about safety or thinks about the compromises he makes. And let's make the young pilot a hot head who never learns how to cool it. Okay, now for the antagonist. He should be a greedy guy, and let's not spend much time on him.
As a result of this type of thinking, we have main characters who only marginally influence each other, and not even in a believable way. The main crisis is such a forced (and even trite) situation that not even the main characters seem to take it seriously. There's no real danger, no real threat, and no real growth.
Gibson is extremely restrained in this role. It's as if he were wrapping a cloak around himself in preparation for becoming Hamlet (his next role). His restraint has the curious effect of making his character seem wooden. He's never been worse than in this movie. The script (at least the script as we hear it) doesn't give him much to say, but he has always risen way above any role he has played. Maybe the problem is with excessive exposition: you can hear him reading the words. Or maybe he was holding back, maintaining a reserve for Zeffirelli (his next director).
Robert Downey, Jr., does well enough, but his character was not very interesting. He's managed a couple of nice moments, and he interacts well with the other cast members, but that's about it.
Apparently, the filming, which was done in Thailand, was quite a strain on everyone. The monsoons couldn't have been very pleasant. And they really did have a 6.1 earthquake plus aftershocks. The entire cast and crew had to suffer through a myriad of inoculations as well as worry about snakes and various nasty critters (including Siamese baby pigs. Really. They're carrying some bizarre, fatal disease. Would I kid you?). Gibson's usual stuntman either wasn't available or left part-way through the film (I'm not sure which). A myriad of personality clashes tangled matters even further. Altogether a difficult prospect to film.
Some directors can profit very handsomely by filming in a location that increases stress: the conflict between characters is heightened, and the location itself becomes part of the conflict. However, this director didn't focus the discomfort. Instead, he tried to keep things light and comedic. He tempered the conflict. He was wrong, and we're the ones who pay. .
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Dear ,
Thank you for booking through Candyland. We hope you enjoyed using our platform.
Your order number is: #. Here are your order details:
Forever yours,
the Candyland team


You selected '{{ establishment.mainService.name }}' as your main service when you created your account.
Select all that apply.