XRDSP 2007-11-13 Meeting
From I-names Development Wiki
Contents |
About
These are the notes from the XRDSP telecon held Tuesday 2007-11-13, 10AM PT.
Attending
- Kermit Snelson
- Victor Grey
- Markus Sabadello
- Andy Dale
- John Bradley
- Drummond Reed
Intro
We agreed that the goal of this work is a standard protocol that can be used to provision XRDS documents.
Terminology
- User – the entity represented by an XRDS
- XRDS (or XRDS document) - as specified in XRI Resolution 2.0 CD02
- XRDS Provider (or just Provider) – the publisher of the XRDS
- XRDS Consumer (or just Consumer) – the party wishing to provisioning SEPs or Synonyms to an XRDS
- SEP – an XRDS service endpoint
- Synonym – an XRDS synonym element that is provisionable by a third party
Use Cases
General
There was consensus that there are two high-level use cases:
- SEP Provisioning: a User wants to authorize an XRDS Consumer to add/modify/delete a SEP in the User’s XRDS.
- Synonym Provisioning: a User wants to authorize an XRDS Consumer to add/delete an EquivID or CanonicalEquivID in the User’s XRDS.
Async
The following async use cases should also be in scope:
- Preauthorization of initial provisioning: allows a User to authorize a SEP to be provisioned in advance of the Consumer coming to the Provider to do the provisioning.
- Preauthorization of subsequent updates (“ongoing permissioning” or “persistent permissions”): same as above, except the User keeps the authorization in effect until it is revoked by the User.
- Post-authorization: The Consumer contacts the Provider but the User is not offline and has not provided permission yet, so the Provider must get permission from the User. (Note: this has the potential to produce user spam.)
Related Technologies
XPP
- XPP wiki and spec at http://xpp.seedwiki.com.
- Tightly modelled around OpenID.
- The XRDS Consumer sends the XRDS Provider the changes it wants to make using a redirect.
- The only differences from the Oauth flow were:
- The Consumer used a URL to describe the SEPs it wants to provision.
- The Provider dereferenced the URL to obtain the description.
Oauth
- See spec at OAuth website.
- Did not exist when XPP was first created.
- Consumer first asks Provider for request token.
- Provider gives it to Consumer, who then redirects User to Provider for permission.
- Reads like a “design pattern”
- Gets us a well-vetted security protocol for third-party authorization.
Issues
Security
- The XRDS is the “keys to the kingdom”. Making provisioning changes must be highly secure.
- The authentication SEP is particularly important.
- The protocol needs to protect against injection attacks.
- The protocol should not accept a block of XML, but should accept the different parts as individual components.
Other
- How do you uniquely identify an SEP you want permission to change? (Note: identifying Synonyms is easy because they are XRIs).
- Permissioning of multiple Consumers to edit the same SEP. (This issue only arises up if permissions are persistent.)
Next Steps
Overall Plan
- There was consensus that we want to create a new protocol for XRDS Provisioning (XRDSP) based on OAuth.
- We’ll use the acronym to XRDSP to prevent collision of “XPP” with the extensible version of EPP and a bunch of other XPP acronyms.
- The scope may include the concept of providing a directory or other resource listing of well-known SEPs.
- The protocol will need a simple and unambiguous permissioning description vocabulary.
Action Items
- JOHN to create Plaxo Group called XRDSP and invite all of us. (DONE)
- DRUMMOND create an XRDSP branch of the Mediawiki at dev.xri.net. (DONE)
- KERMIT to provide feedback to Andy on the existing XPP spec at xpp.seedwiki.com.
- ANDY to review Oauth and create a strawman.
- DRUMMOND to request from Kaliya an XRDSP working session for the first day of IIW (Monday Dec. 3).
Next Meeting
The goal is to hold the next telecon in two weeks. Placeholder time: 10AM PT Tuesday 11/27, to be confirmed on the Plaxo XRDSP mailing list.
