For OpenMicroBlogging, we use the root URL of the Consumer microblogging service as the Consumer Key, and a blank string '' as the Consumer Secret. The following draft, for your review, defines a method to automatically negotiate a somewhat more reliable Consumer Secret value.
-Evan ==================================================== OICU2: Establishing Consumer Identity with HTTP URLs ==================================================== :Author: Evan Prodromou (Control Yourself, Inc.) :Contact: [email protected] :Revision: 0.1 :Date: 2009-01-10 :Copyright: To the extent possible under law, Control Yourself, Inc has waived all copyright, moral rights, database rights, and any other rights that might be asserted over The OpenMicroBlogging specification. Purpose ------- OAuth [1]_ requires a Consumer Identity for each request, and identity provision is out-of-band. OAuth Discovery [2]_ identifies two mechanisms for establishing identity: a static identity (one identity for all consumers) and out-of-band establishment. This document defines another mechanism for establishing a Consumer Identity, for the limited use case where: 1. the Consumer can be identified with an HTTP URL 2. the Service Provider can authorize or refuse a Consumer automatically The first limitation can be met by a wide class of Consumers -- both Web sites and Web-connected applications. The second requirement is met by many applications, where all comers are welcome, but some bad players may be refused automatically (for example, by using a realtime blackhole list like SURBL [3]_ or a DNSBL [4]_). The method provides a slightly better security model than static identity establishment, in that verified HTTP URLs can often be used to establish human-to-human contact when there are problems. Service Providers may also use the URL-as-identifier to limit later requests, especially if those requests include URLs. .. [1] http://oauth.net/core/1.0 .. [2] http://oauth.net/discovery/ .. [3] http://www.surbl.org/ .. [4] http://en.wikipedia.org/wiki/DNSBL Overview -------- Consumer Identities, in this system, consist of two parts. The Consumer Key is an HTTP or HTTPS URL. The Consumer Secret is an opaque token. To retrieve this token, the Consumer makes a request to the Service Provider, including an arbitrary private identifying value: the Confirmation Token. The Service Provider makes a call back to the Consumer, using the identity URL, to validate the Confirmation Token. If the token validates, and the Service Provider otherwise approves the Consumer, it returns a new Consumer Secret value. Discovering request support --------------------------- The Service Provider can advertise a willingness to perform this kind of identity discovery using OAuth Discovery. The service descriptor file must include a service stanza of type: http://oicu2.net/0.1/consumerSecretRequest The service URI is required, and must be the endpoint for the consumerSecretRequest method described below. If the Consumer has previously retrieved a Consumer Secret value from the endpoint, it should use that previous secret. consumerKeyRequest ------------------ To request a Consumer Secret value, the Consumer makes a signed request to the consumerSecretRequest URL. The request must use the Consumer's URL identity as the Consumer Key, and a blank string as the Consumer Secret. It should include one additional parameter: oicu2_confirmation_token An arbitrary private identifying string value. The Service Provider should confirm the token with the consumer's Web site, using the process described below. If successful, results will be: oicu2_consumer_secret A secret value If multiple requests to this endpoint are made with the same URL as Consumer Key, the validity of earlier returned consumer secrets is undefined. They may remain valid, or they may be obsoleted by the new secret. Discovering confirmation support -------------------------------- The Service Provider can discover the confirmation endpoint support using XRDS service discovery [5]_ on the URL provided as the Consumer Key. The consumer must define a service of type: http://oicu2.net/0.1/validateConfirmationToken The URI of this service can be used as the endpoint for a call to validate the confirmation token. .. [5] http://xrds-simple.net/core/1.0/ validateConfirmationToken ------------------------- To validate a confirmation token, the Service Provider makes a signed request to the endpoint defined by the XRDS discovery process. The Consumer Key for the request is an URL for the Service Provider, such as a root URL or the URL of the protected resource, and the Secret is the blank string. The request must contain one additional parameter: oicu2_confirmation_token An arbitrary private identifying string value. The result will be: oicu2_confirmation_token_valid A string, 'yes' or 'no'. Example ------- A user, Brenda, would like to authorize their photo-sharing service at http://photo.example.com/ to post notices of newly uploaded photos to her social networking account at http://social.example.net/brenda. photo.example.com and social.example.net have no previous relationship. 1. The consumer at photo.example.com generates an arbitrary confirmation token value and stores it in a private database. (Note: there may be other mechanisms for generating a confirmation token, such as using a static token.) 2. The consumer requests the HTML page for the protected resource at http://social.example.net/brenda, and extracts the URL for the XRDS-Simple file used by OAuth Discovery. 3. The consumer retrieves the XRDS-Simple file, and seeks a Service element of type http://oicu2.net/0.1/consumerSecretRequest. 4. The consumer checks if it has already retrieved a consumer secret from the URI of that Service element. If it had, it would continue with the OAuth core process. Since it has not, it continues. 5. The consumer uses the URI of that Service element to make a signed request, using 'http://photo.example.com/' as the Consumer Key, and '' as the Consumer Secret. It includes the confirmation token as the oicu2_confirmation_token parameter. 6. While processing this request, the social network requests the HTML page at http://photo.example.com/, and extracts the URL for the XRDS-Simple file. 7. The social network retrieves the XRDS-Simple file, and seeks a Service element of type http://oicu2.net/0.1/validateConfirmationToken. 8. The social network posts a request to the URI of that Service element, using 'http://social.example.net/' as the Consumer Key, and '' as the Consumer Secret. It includes the confirmation token it received as the parameter oicu2_confirmation_token. 9. The photo-sharing site's confirmation endpoint checks if the passed-in token is in its database. Since it is, it returns an oicu2_confirmation_token_valid result with value 'yes'. 10. On receiving the validation result of 'yes', the social networking site generates an arbitrary value to use as a consumer secret, and stores it in a private database for future verification. (Note: one possible implementation.) It returns the consumer secret as the oicu2_consumer_secret return value. Security considerations ----------------------- - This verification technique relies on DNS and is subject to attacks using, for example, DNS poisoning. - The oicu2_consumer_secret is returned in the clear and is subject to man-in-the-middle attacks. It may make sense to use HTTPS for most or all of this protocol. - Both service provider and consumer pass URLs to their protocol partners that are then to be read. These URLs could be formulated to deny service to the calling process, by returning far too much content, or never returning, or otherwise behaving badly. - Statically-allocated confirmation tokens may be subject to replay attacks. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
