I'm confused. How is my UMA Authorization Server supposed to use the Privacy Policies and Terms of Service? Are we assuming some highly standardized data model around some 50 aspects of what Facebook might or might not do with my data before UMA can work? The degree of domain and business specificity that this approach implies seems totally impractical.
I see service provider assertions such as Privacy Policy and Terms of Service as secondary to UMA, to be considered off line at the time when the RO either registers an AS with an RS or walks away. These policies will also enter into dispute resolution.
The only link between these policies and the AS could be that the RS must specify which of the 50 clauses applies to a specific transaction to be authorized by the AS. In most cases, this metadata would not be "understood" by the AS but it would be part of the transaction logs. Occasionally, it could be linked by the RO to specific AS behavior as a kind of exception. For example, I might configure my AS to reject authorizations bearing the Facebook Policy Tag 7g without any particular standard or policy calculus.
From my perspective, the principal role of my AS is to introduce convenient _centalized_ transparency and notice into the data use practices of my service providers along with an opportunity to occasionally opt out of a transaction.
Adrian
On Wednesday, September 30, 2015, James Hazard <
jh@hazardj.com> wrote:
One of the Facebook documents and one of the Twitter documents are now in component form. On the Facebook doc, there are some names for section components, positing a taxonomy. These names (mostly verbs) are simply a guess, and non-exclusive (the same materials can be recombined using different names). But, IMHO, evocative. In any event, a starting point.
Both docs live in this tree:
A theory of such trees is at:
--