Group Membership (zh-cn)

English | 日本語 | ‪中文(中国大陆)‬ | +/-

The following describes a simple protocol for determining the membership of a given URI in a set.

There are several applications for determining group membership of a URI. Many of these are trust-related. For example, I may wish to give anyone who has admin access on a third-party site B equivilent access on my own site A. In a more general sense, it can also be used as a query protocol for white, black or greylists.

This protocol considers a group to be a set where every URI for all possible URIs is either a member or not a member of the set. Note that these URIs do not have to be OpenID Identifier URIs, nor do they have to be resolvable. How the endpoint determines group membership is not defined in the protocol.

Groups are themselves identified by URIs, though group URIs do need to be resolvable and, as currently specified, must be HTTP or HTTPS URLs.

Contents 1 Basic Protocol 2 Efficiency Considerations 3 Security Considerations 3.1 Secure Channels 3.2 Authentication 4 Extra Notes 4.1 Rationale for not using Yadis discovery

Basic Protocol

• Questioning party sends a GET request to the Group URL. In response, it will either get an HTTP header field X-Group-Membership-Endpoint or an HTML document containing an equivilent META HTTP-EQUIV element in its HEAD. This field has as its value another HTTP or HTTPS URL (which MAY be the same as the Group URL) where the group's lookup endpoint is located.
• Questioning party sends a GET request to the lookup endpoint URL, appending a query string ?lookup_uri=http://someuri.com/&group=http://example.com/. The query string is appended following the same rules as are used for preparing query URLs in OpenID authentication.
• Endpoint URL responds with an XML document with a root element in the namespace http://openid.net/ns/group-membership (to be confirmed) with a local name of either 'member' or 'non-member'. This element must have an attribute 'uri' which identifies the URI that this membership assersion applies to, and 'group' which identifies the group. RPs MUST ensure that these URIs match the URIs given in the request. The "member" root element indicates that the URI is a member of the group. The "non-member" root element indicates a non-member. Both members and non members can have child elements providing further information. This root element MAY contain child elements in other namespaces, though their significance is not defined in this protocol. For example, this response could indicate that the book with this particular ISBN has been read by someone; a hypothetical element in a separate namespace is used to point to a review of the book:

      <group:member uri="urn:isbn:0007203373"
                    group="https://person.example.com/groups/books-i-have-read"
                    xmlns="http://openid.net/ns/group-membership">
          
          <review xmlns="http://xmlns.example.com/reviews" uri="https://person.example.com/bookreviews/0007203373" />
          
      </group:member>
  

Efficiency Considerations

This protocol is designed to suffer a minimal overhead while preserving the ability to separate the group URI (which will often be a static HTML document) from the endpoint URL. Questioning parties MAY cache the group's endpoint URL for a reasonable amount of time, but they MUST follow a reasonable amount of HTTP Redirect responses when making requests to the endpoint. If an HTTP error response is recieved from the remote server when making a request using a cached endpoint URL, the questioning party SHOULD invalidate its cache and do discovery as described above to determine if the endpoint has changed; it SHOULD then repeat the query to the new endpoint.

Security Considerations

Secure Channels

Groups which have their own URL and/or their endpoint URL on a non-secure server may be vulnerable to a variety of spoofing attacks which could allow malicious third-parties to respond in place of the group's authoritative endpoint. For sensitive applications, serving both of these URLs over some kind of secure channel (TLS or SSL, for example) is HIGHLY RECOMMENDED.

Authentication

Endpoint URLs MAY require authentication in some form in order to satisfy a request. Endpoint URLs MAY respond with a standard 401 Unauthorized response indicating that the questioning party must use some form of HTTP authentication to continue the request, or MAY use some other implementation-defined authentication mechanism. However, implementors should take the usual measures to ensure that sensitive information is not cached in public HTTP caching proxy servers.

Extra Notes

Rationale for not using Yadis discovery

This protocol does not make use of Yadis discovery in order to decrease overhead, since group membership lookups are likely to be performed regularly in many applications.