XRDSP Spec

From I-names Development Wiki

OAuth References

This specification assumes a working knowledge of the OAuth Protocol as published in “OAuth Core 1.0 Draft 7” at http://oauth.googlecode.com/svn/spec/branches/1.0/drafts/7/spec.html as it only specifies those parts of the interactions that are not specified in the OAuth specification.

XRDS High Level Architecture

XRDSP leverages the authentication pattern established in the OAuth specification for users to let one of their services access another of their services on their behalf. OAuth assumes a pre-existing trust relationship between Service Providers (OAuth consumers) and XRDS Providers (OAuth service providers) that can not necessarily be assumed for the XRDSP scenarios; for this reason XRDSP establishes a Consumer Registration Protocol that lets the two parties establish a basic OAuth trust relationship as part of the XRDSP APIs. Once a Service Provider has registered at a XRDS Provider they will have the Consumer Key and Consumer Secret necessary to acquire Request and Access Tokens. In addition to the Consumer Registration Protocol XRDSP specifies the the Parameters that will be used in addition to the standard OAuth request parameters and how those parameters must be validated and presented by compliant XRDSP implementations.

XRDSP Specifications

Consumer Registration

This portion of the XRDSP specification establishes the endpoints, identifiers and data relationships that must be in place for a Service Provider to establish a trusted relationship with an XRDS Provider.

In order to establish on the fly authentication with a previously unknown entity we are going to use the trustworthiness of the XRI resolution network. When a Service Provider wants to register with an XRDS provider they will do so by simply passing their i-name to the XRDS Provider through the RegistrationRequest() method call. All other information that is needed to establish the registration will be 'pulled' from the Service Provider's XRDSP_SP End Point. This ensures that the information MUST pertain to the, and originate from the, entity that controls the XRDS that contains the XRDS_SP End Point for the asserted i-name. The XRDS Provider must therefore provide a Consumer Key and a Consumer Secret that is tied to the Canonical ID of the XRDS that contains the XRDS_SP End Point found by resolving the given i-name.

The Consumer Key and the Consumer Secret will be delivered to the Service Provider by the XRDS Provider by invoking the RegistrationRequestResponce() method call at the Service Providers XRDSP_SP End Point. The Consumer Key and Consumer Secret will be parsed to the RegistrationRequestResponce() call encrypted with the Service Provider's public key so that only an entity that has access to the Service Provider's private key will be able to decrypt that payload. The Service Provider's public key will be obtained by invoking the PublicKeyRequest method on the XRDS_SP End Point.

Key Pairs

It will be sufficient for the Service Providers to use self signed OpenSSL RSA key pairs. <<specify exact parameters>>

Resolution

While individual users who want to use XRDSP can have either an OpenID URL or an OpenID i-name that resolves to XRDS; Service Providers and XRDS Providers MUST have an XRDS that is resolvable in the XRI network so that XRDSP can make full use of trusted resolution and Canonical ID validation. When performing service endpoint discovery both the Service Provider and the XRDS Provider MUST perform Canonical ID Verification.

Sequence

<<Add Sequence Diagram of interactions>>

Already Registered <<What happens if the Service Provider is already registered at the XRDS Provider>>

<<How does a Service Provider recover from a lost Consumer Key or Secret>>

XRDSP Parameter Requirements

These parameter are the mechanism by which the specific XDRS changes are communicated from the Service Provider to the XRDS Provider. This portion of the specification will include how these parameters should be processed and displayed to the user to ensure that they are fully informed as to the changes that they are being asked to approve.

<<MECHANICS GO HERE>>

XRDSP Implementations By adhering to the referenced OAuth specification and the XRDSP specifications an implementor should have an unambiguous set of instructions that will provide full interoperability between all XRDSP implementations. There should be no 'policy' decisions unspecified that would introduce non-interoperable implementations.

End Point Specifications

XRDSP_SP End Point

The XRDSP_SP End Point is an endpoint that MUST be provided by any Service Provider that wants to make use of XRDSP to request changes in an XRDS Document. The XRDSP_SP End Point MUST implement BOTH the Consumer Registration API and the Request Token Parameter API in order to be compliant with this specification.

SEP Type

For the sake of Service End point discovery the XRDSP_SP End Point MUST be identified as Type= xri://+XRDSP*(+SP)*($v*1.0)

Consumer Registration Functional API

RegistrationRequestResponce Input Parameters: nonce – a string value that was returned from the RegistrationRequest() call encrypted(consumer key, consumer secret) - a key and secret that can subsequently be used by the Service Provider to establish its identity to the XRDS Provider. Return Parameters: restultCode – indicates... success – everything was expected and worked unknown nonce – this seems to be a response to an unknown request incorrect cryptography – the consumer key and secret can not be extracted

PublicKeyRequest

Input Parameters: NONE Return Parameters: public key <<X509 cert?>>

Interface Bindings

The functional interface will be bound to an HTTP get/post based transport. All XRDSP_SP interactions SHOULD be executed across SSL conections.

<<complete binding details>>

Request Token Parameter Functional API

getSEPSingnature

<<specify>>

Interface Bindings

The functional interface will be bound to an HTTP get/post based transport. All XRDSP_SP interactions SHOULD be executed across SSL conections.

<<complete binding details>>