DP1

Simple

Simple to understand, implement in an interoperable fashion, and deploy on an Internet-wide scale

DP2

OAuth

OAuth-based to the extent possible

We may contribute bug reports and RFEs around extensibility, security, and privacy to the IETF OAuth group.

DP3

ID-agnostic

Agnostic as to the identifier systems used in an individual's various services on the web

This is in order to allow for deployment in "today's Web".

DP4

RESTful

Resource-oriented (for example, as suggested by the REST architectural style) and operating natively on the Web to the extent possible

DP5

Modular

Modular

For example, incorporating other existing specifications by reference where appropriate, and breaking down this Work Group's draft specifications into multiple pieces where reuse by different communities is likely.

DP6

Generative

Generative

Able to be combined and extended to support a variety of use cases and emerging application functionality.

DP7

Fast

Developed rapidly

In an "agile specification" process that can refactor for emerging needs.

DP8

Cryptography

We should avoid adding crypto burdens as part of our simplicity goal

Avoid adding crypto requirements beyond what existing web app implementations do today. This principle was discussed on 2009-09-10.

DP9

Privacy

Protect the privacy of the Authorizing User

The protocol should not provide ways to breach the Authorizing User's privacy, though out-of-band methods are beyond our control. Also, this principle should not be construed as support for protecting the privacy of other parties, or even the same person in a different role (the Requesting User). This principle was discussed on 2009-10-08.

DP10

Complexity

Complexity should be borne by the AM endpoint vs. the host or requester, if possible

We anticipate dozens of AMs (maybe lots more if corporations have them), hundreds of thousands of hosts, and hundreds of millions of requesters. This principle was discussed on 2009-11-02.

DP11

Authentication

Stay out of the authentication business as much as possible

There are many technology choices here. Some scenarios may need stronger authentication. OAuth will be our preferred means of service authentication per DP2, but even it could be supplanted. This principle was discussed on 2009-11-02.

DP12

User experience

Ease of end-user experience should inform our protocol design

Even though the goal for authorizing users is to allow them to set policy that can applied without inconvenience to them at run-time, the mechanisms of introducing hosts to AMs, setting policy at AMs, auditing access at AMs, and provisioning resource locations to requesters should be as easy as possible. This principle was discussed on 2010-03-18.

DP13

Digital signatures

Don't preclude strong authentication through digital signatures, and leverage widely supported signature solutions as options if a reasonable measure of interoperability can be achieved

We see opportunities to leverage JSON Web Tokens, which didn't exist when the group was first launched, and we have more overall experience with judging what is "reasonable" vs. "undue" crypto burdens now (see DP8, "Cryptography"). This principle mitigates the potentially heavy-handed effects of DP1 ("Simple") and DP10 ("Complexity") in forcing bearer tokens as a universal solution. Finally, this principle is consistent with DP11 ("Authentication") if we leverage a widely supported external solution for digital signatures and avoid defining a whole new one. This was discussed primarily on 2011-01-27 and 2011-02-10.