XRDSP Requirements

From I-names Development Wiki

Contents 1 About 2 Terms/Actors 3 General 4 Functional 4.1 Open Issues 5 Usability 6 Security 7 Privacy 8 Accountability

About

This page summarizes the requirements for the XRDS Provisioning protocol.

Terms/Actors

• User – the actor ultimately in control of an XRDS document.
• XRDS Document – an identity service discovery document for the User hosted by an XRDS Provider as defined by XRI Resolution 2.0 Committee Draft 02.
• XRDS Provider – the actor hosting the XRDS document and exposing the XRDSP interface. From an OAuth perspective, this is the Service Provider.
• XRDS Consumer - the actor that needs to provision a SEP in the User’s XRSP. From an OAuth perspective, this is the Consumer.
• SEP – Service Endpoint in an XRDS document.
• Permission – authorization for an XRDSP operation that can be requested by an XRDS Consumer and granted or revoked by a User.

General

1. The protocol MUST be as simple as possible (but no simpler) and easy to implement.
2. The protocol MUST work with any OpenID-addressable XRDS document, i.e., XRDS documents that represent URLs (HTTP(S) URIs), XRIs, or any combination.

Functional

1. The protocol MUST enable an XRDS Consumer to provision any SEP in an XRDS document.
2. Provisioning functions covered by Permissions MUST include:
   1. Add a SEP (including priority).
   2. Modify a SEP (all attributes and elements, including priority).
   3. Delete a SEP.
   4. The protocol MUST enable the XRDS Consumer to provision any valid SEP as defined by XRI Resolution 2.0 Committee Draft 02. This includes SEPs containing elements or attributes from other namespaces.
3. The protocol MUST allow the User to grant, and the XRDS Provider to enforce, Permissions that persist beyond the initial authorization session, i.e., that enable the XRDS Consumer to perform a XRDSP operation without the User being present.

Open Issues

1. Should the protocol also be able to provision the following XRDS synonym elements: EquivID, CanonicalEquivID?

Usability

1. The protocol MUST enable an XRDS Consumer to communicate to an XRDS Provider, and an XRDS Provider to communicate to a User, adequate information for the User to provide explicit informed consent to the authorization decision the XRDS Consumer is requesting.

Security

1. The protocol MUST authenticate the User and the XRDS Consumer and provide reasonable assurance that only the XRDS Consumer authorized by the User can perform the XRDS operations for which the user has granted Permissions.
2. The protocol MUST NOT imply that just because just because an XRDS Consumer can authenticate that they are trustable.

Privacy

1. The protocol MUST ensure that only the User, XRDS Provider, and XRDS Consumer have access to the Permissions granted to that XRDS Consumer by the User.

Accountability

1. The protocol MUST provide adequate information for implementers to be able to ensure that the User and XRDS Provider can account for the actions taken by any XRDS Consumer.