LID Relying Party Service

From LID Wiki

Contents 1 Relying Party Profile 1.1 Indication of Relying Party 1.1.1 Graphical indication 1.1.2 Indication in the protocol 1.2 Session cookies 1.3 Changing identities and Logoff 2 Personal LIDs(tm) as LID(tm) Relying Parties

Relying Party Profile

Note: Recent updates reflect the simplified algorithm using one-way nonces.

A LID Relying Party is found at a certain URL, such as http://www.example.com/some/where. (You can try one out at http://firstsso.netmesh.org/.) It knows how to evaluate the following parameters in order to determine the identity of the party requesting a service at that URL:

• lid: the LID(tm) URL of the party requesting the service;
• lid-nonce: a nonce provided by the party requesting the service that prevents Replay Attacks;
• lid-credtype: the type of credential provided by the party requesting the service;
• lid-credential: the credential provided by the party requesting the service;

All four parameters must be provided, or the request is not considered valid.

Having evaluated the provided identity, nonce and authentication information, the LID Relying Party may then decide how to serve the request (including denying the request, serving the request as if no identity information had been provided, or serving the request differently).

If the LID Relying Party does not accept the provided credential (e.g. because the electronic signature on the request was invalid, or the nonce had already been used), it applies the following algorithm:

• if a lid parameter was given, and its value refers to a valid LID(tm) URL (the LID Client's), the LID Relying Party will respond with an HTTP redirect response, redirecting the user agent to the client's LID(tm) URL, with the following parameters:
  • lid-target: the URL of the LID Relying Party;
  • lid-target-credtype: the credential type or credential types that the LID Relying Party is willing to accept;
  • lid-action=sso-approve: indicates that the LID Relying Party would like the client LID(tm) URL to approve the LID(tm) SSO request.

To evaluate the validity of a nonce provided using the lid-nonce parameter, the following algorithm is used by LID Relying Partys that wish to protect against Replay Attacks:

1. check that the format of the nonce is of the form YYYY-MM-DDThh:mm:ss.sssZ where YYYY: year, MM: month, DD: day, T: literal character T, hh: hour in 24-hour format, mm: minute, ss.sss: seconds in millisecond resolution, Z: literal character Z, per ISO 8601 (overview) in extended format in the UTC time zone. See also LID SSO Profile.
2. check that the time stamp expressed by the nonce is within a limited time interval from the current time. The size of the time window may be decided by the implementor of the LID Relying Party and should be chosen in a manner that does not produce problems with clock skew of the magnitude typical on the internet.
3. check that this nonce has not been used already by the same client (as identified by its LID URL) during the time window. In order to accomplish this, the LID Relying Party must implement some mechanism of keeping track of past nonces, up to the times defined by the time window.

Indication of Relying Party

Graphical indication

See LID 2.0 Look and Feel.

Indication in the protocol

Note: using a cookie for this purpose has turned out to be unwieldy. Given the simplicity of RFC 2774 (HTTP Extension Framework), an HTTP protocol extension turns out to be simpler and more consistent with the goals and common uses of HTTP cookies.

A LID Relying Party identifies itself to the world using an optional HTTP extension, in the http://lid.netmesh.org/ namespace. (This namespace may be used in the future for additional HTTP protocol extensions in connection with LID.)

Within this namespace, the header name org.netmesh.lid.relying-party identifies the requested resources as a LID Relying Party. The header value indicates the version number or version numbers of the LID Relying Party that are supported, using the same value string that is defined in response to the ?meta=lid query defined in MinimumLID.

For example,

Opt: "http://lid.netmesh.org/"; ns=47
47-org.netmesh.lid.relying-party: 2.0,2.1

in the response to an HTTP request to a certain URL indicates that the URL refers to a LID Relying Party that supports the LID Relying Party Profile in versions 2.0 and 2.1. (Note: this is hypothetical, there is no version 2.1 yet for the LID Relying Party Profile).

A search engine, for example, could use this to determine which of the URLs it indexes are LID Relying Partys.

Session cookies

For efficiency reasons, a LID Relying Party typically wants to issue a session cookie that identifies the user agent session for a certain time period. For that period of time, the user agent does not need to be redirected to the LID(tm) URL according to the protocol described above.

By convention, that session cookie is called org.netmesh.lid.session.

Once the session cookie expires, the LID Relying Party must re-authenticate the user by redirecting to the LID(tm) URL again as described above.

A suitable time period for the validity of the session cookie can be determined using the LID_2.0_Mechanics_Profile. Note that the time period must be enforced by the LID Relying Party through a mechanism other than cookie expiration (otherwise Replay Attacks would be possible even after the time period has expired).

Changing identities and Logoff

If a currently authenticated user (such as through a session cookie) performs an operation on a LID Relying Party that specifies a different LID(tm) URL than the LID(tm) URL of the current session, the LID Relying Party shall interpret this as

1. a non-negotiable logout from the currently used LID(tm) digital identity, and
2. a request to log in with the new LID(tm) URL as the identity. This request may or may not be granted, depending on the provided credentials and the site policy.

In the special case of the following URL arguments for the LID Relying Party:

• lid= (an empty LID(tm) URL)

the user agent wishes to terminate the session and log out. The log out must be effective immediately; no "confirm" screens are allowed.

Personal LIDs(tm) as LID(tm) Relying Parties

Two classes of scenarios may cause a Personal LID to also be a LID Relying Party:

1. The LID(tm) URL supports queries or other operations according to LID_2.0_Traversal_Profile or any other profile that needs to produce different results depending on the identity of the client, and that needs clients to be authenticated using the LID Relying Party Profile.
2. The LID URL Owner must authenticate themselves against their own LID(tm) URL, in order to, for example, approve SSO requests.

In LID(tm) 1.0, the protocol by which the LID URL Owner authenticated against their own LID(tm) URL was outside of the definition of the LID(tm) protocol. In LID 2.0, we will use the LID Relying Party Profile to accomplish the same thing without having to step outside of the LID(tm) protocols or having to extend them.

While the number and credential types that a LID Relying Party accepts is open to implementors (beyond the minimum standards defined in LID Relying Party Profile), it often may make sense for LID Relying Partys that are also personal LID(tm) URLs to accept a simple LID Password Credential. In this case, the owner of the LID(tm) URL would specify his very own LID(tm) URL as the lid parameter, set the credential type to lid-credtype=simple-password according to LID Relying Party Profile and send his password using the credential parameter. (See also LID Password Credential.)