The Binding Obligations draft factors out descriptions of such functions first according to the party serving in the role and then according to the party to whom those functions are “owed”. For example, Section 2.4 contains the “obligations” of the Authorization Server Operator (the party operating the software service that performs the function of the UMA authorization server); Section 2.4.1 contains an “obligation” to the Authorizing Party (the party corresponding to the UMA resource owner), Section 2.4.2 contains an “obligation” to the Resource Server Operator (an party operating a software service that performs the function of an UMA resource server), and so on.

If you look in Sec 2.4.1, you’ll see text like this:

“When the Authorization Server issues a PAT to the Resource Server and as long as the PAT is valid, the Authorization Server Operator gains an obligation to the Authorizing Party to adhere to the Authorizing Party's policies accurately and timely in granting permissions.”

For now, we can put aside the When…, the [party] gains construction, and save it as an idea for an optional model clause that could come into play if some legal team or individual wants to create an audit log entry/consent receipt requirement.

Also note that what is called an “obligation”, I think may want to be a “commitment” or “prohibition” or “sanction” (or one of the other two norms coming from the sociotechnical norm work). This would be more precise, and we could define those norm terms up front.

Does this give a good direction for how we could “CommonAccordionify” our work?? :-)

All this said, I don’t know if the Binding Obs set of “obligations” is the right set, inadequate, overstated, or legally wrongheaded! I’m sort of hoping that if we can make a run at accordionifying it, then the legal minds can really stare at it in familiar contract form and see what they think.

Thanks,

Eve

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com