Happy to work when you are home. I'm busy all tomorrow but otherwise mostly available. My guess is that it makes sense to sketch from a couple of perspectives and see where things fit together. One perspective is kind of minimum viable interaction - one person (P1, unsophisticated, busy) wants to trust some info to someone else (P2, sophisticated) - and P1 wants the benefit of community knowledge. That could be formalized as a "normal" exchange of contract offer, acceptance. This kind of thing, padded with some boilerplate: http://www.commonaccord.org/index.php?action=source&file=Wx/org/consentreceipt/api/Signature/24_Demo_Acme_Robinson_Acceptance_v0.md So making boilerplate padding that covers the basics and can be easily adapted would be a good goal that would fit with a very broad range of uses. Another perspective is that a set of rules like the Binding Obligations as a whole (or ID Federation http://www.commonaccord.org/index.php?action=source&file=GH/FutureCommerce/StandardLaw/IDFederation/Form/Doc_v0.md) is how markets operate - charters are better than piecemeal. Inclusion (transclusion) lets these blend together. We could start at either end. Or at both ends, unlike the guys digging the tunnel, we could have confidence that we would meet in the middle. For the piecemeal, one-contract-at-a-time approach, I would think that replicating (with slight improvements) contracts or ToUs currently in use would keep us on track. Just my impressions. On Fri, Dec 4, 2015 at 1:57 PM, Eve Maler wrote:

Does it make sense to organize these as the "business" terms and leave room for "legal" and "technical" ones? Are they all in a "business" category

Would you be interested to add the "norm" definitions and try some mappings (as discussed last week and as I've shared on the list previously) from "obligation" thinking to norm thinking?

Does it make sense to factor out the temporal stuff into optional transactional receipt clauses?

(I could attempt this type of stuff once I'm home -- maybe in a working session with you?)

Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

On Dec 4, 2015, at 11:01 AM, James Hazard wrote:

This looks good. FYI, the terms are also available (Accordified) at:

http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative/UMA/2013/2.md (I may simplify the intra-document naming, but that won't affect this link.)

On Fri, Dec 4, 2015 at 10:52 AM, Eve Maler wrote:

...

The Binding Obligations https://docs.kantarainitiative.org/uma/draft-uma-trust.html 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 https://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor16 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 https://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor17 contains an “obligation” to the Authorizing Party (the party corresponding to the UMA resource owner), Section 2.4.2 https://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor18 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 http://www.csc.ncsu.edu/faculty/mpsingh/papers/mas/TIST-13-governance.pdf 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

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Makes sense to me. Three use cases for an offer-acceptance flow: 1. Free-range - we aren't UMA. Maybe P2 gets its terms from some other (in their view better) source or maybe P2 rolls its own. 2. We are UMA. The flow of offer-acceptance leads to the UMA principles enhanced with legal language and commentary developed by UMA community that makes it clear and enforceable. 3. We are UMA modified. P2 incorporates (by reference or transclusion) UMA Binding Obligations and Boilerplate, but modify (fork). Bz of modularity, forking is "cheap" and therefore not bad (as per GitHub), so this is how best practices (as well as deviations) develop. Note that P1 could also be the initiator, and advocacy groups (Mark?!) could do the work and make the case for them. On Fri, Dec 4, 2015 at 3:01 PM, Eve Maler wrote:

Note that the Binding Obs were written as "axiomatic" requirements expressing the minimum that any actor in an UNA role should be able to promise to do, no matter the use case. Any scenario-specific stuff -- and non-UMA role mappings, such an AS operator that is also an IdP operator -- is where the CmA extension magic can really shine.

Example of what I mean by axiomatic if we were talking about SAML instead of UMA: A SAML IdP that has issued an assertion needs to have done the kind of authentication it says it did, at the stated time, of the named principal. (Maybe with caveats/SLAs driven by Tim's work in the Virginia digital identity law?). The protocol never really says this. Maybe some federation agreements say it; I suspect a lot of them don't.

(And now I'm headed LHR-SEA...)

Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

On Dec 4, 2015, at 1:47 PM, James Hazard wrote:

Happy to work when you are home. I'm busy all tomorrow but otherwise mostly available.

My guess is that it makes sense to sketch from a couple of perspectives and see where things fit together.

One perspective is kind of minimum viable interaction - one person (P1, unsophisticated, busy) wants to trust some info to someone else (P2, sophisticated) - and P1 wants the benefit of community knowledge. That could be formalized as a "normal" exchange of contract offer, acceptance. This kind of thing, padded with some boilerplate:

http://www.commonaccord.org/index.php?action=source&file=Wx/org/consentreceipt/api/Signature/24_Demo_Acme_Robinson_Acceptance_v0.md

So making boilerplate padding that covers the basics and can be easily adapted would be a good goal that would fit with a very broad range of uses.

Another perspective is that a set of rules like the Binding Obligations as a whole (or ID Federation http://www.commonaccord.org/index.php?action=source&file=GH/FutureCommerce/StandardLaw/IDFederation/Form/Doc_v0.md) is how markets operate - charters are better than piecemeal.

Inclusion (transclusion) lets these blend together. We could start at either end. Or at both ends, unlike the guys digging the tunnel, we could have confidence that we would meet in the middle.

For the piecemeal, one-contract-at-a-time approach, I would think that replicating (with slight improvements) contracts or ToUs currently in use would keep us on track.

Just my impressions.

On Fri, Dec 4, 2015 at 1:57 PM, Eve Maler wrote:

...

Does it make sense to organize these as the "business" terms and leave room for "legal" and "technical" ones? Are they all in a "business" category

Would you be interested to add the "norm" definitions and try some mappings (as discussed last week and as I've shared on the list previously) from "obligation" thinking to norm thinking?

Does it make sense to factor out the temporal stuff into optional transactional receipt clauses?

(I could attempt this type of stuff once I'm home -- maybe in a working session with you?)

Eve (sent from my iPhone, possibly with Siri's "help": +1-425-345-6756)

On Dec 4, 2015, at 11:01 AM, James Hazard wrote:

This looks good. FYI, the terms are also available (Accordified) at:

http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative/UMA/2013/2.md (I may simplify the intra-document naming, but that won't affect this link.)

On Fri, Dec 4, 2015 at 10:52 AM, Eve Maler wrote:

...

The Binding Obligations https://docs.kantarainitiative.org/uma/draft-uma-trust.html 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 https://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor16 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 https://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor17 contains an “obligation” to the Authorizing Party (the party corresponding to the UMA resource owner), Section 2.4.2 https://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor18 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 http://www.csc.ncsu.edu/faculty/mpsingh/papers/mas/TIST-13-governance.pdf 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

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma