Jim-- Great job on the refactoring! I'm finally getting a chance to take a quick look. Individual/Legal Person/Person looks good. What do you think about building into the clause skeleton the idea of having potentially multiple "conditions precedent" and "conditions subsequent" as Scott suggested, and multiple "duties" (perhaps with, typically, only one duty defined by us out of the gate)? It may be that bulleted lists will therefore be our friend in terms of standard formatting, and phrases (actually clauses in English grammar, but now that's confusing to say!) with sentential initial caps will be the easiest all around. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Sun, Dec 20, 2015 at 2:37 AM, James Hazard wrote:

Scott -

Following up on the discussion, changes to the Introduction can be made here. Paste a copy of the changed text (or, better, just the lines you change) in an email and send to me. The site is just a presentation of the GitHub repo and changes need to be made at the repo. If you have a GitHub account, you can make the changes there (link at the top) and do a pull request.

Jim

http://www.commonaccord.org/index.php?action=edit&file=GH/KantaraInitiative/UMA-Text/Comment/Introduction_0.md

On Sat, Dec 19, 2015 at 7:22 PM, James Hazard wrote:

...

Very briefly (almost dinner time here) - a refactoring, at:

http://www.commonaccord.org/index.php?action=doc&file=GH/KantaraInitiative/UMA-Text/0.md

Most of the modules have meaningful names and are organized into folders. (click on source and follow links). The defined terms link to the definitions (per suggestion yesterday).

I made many imperial decisions about naming conventions. Most have some thought built in but also have an element of arbitrary, and there are undoubtedly other thoughts they could reflect.

Best, Jim

On Fri, Dec 18, 2015 at 6:37 PM, Eve Maler wrote:

...

- Review the first draft deliverable http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative/UMA/2013/2.md and its model clauses and definitions - How to take our work forward? Continue our subgroup meetings? - AOB

Attending: Eve, Andrew H, Steve, Adrian, John W, Mark, Ann, Jon N, Jim, Scott, Dazza

*How to take our work forward? Continue our subgroup meetings?*

What is the interest in continuing the subgroup meeting series into 2016? Andrew is interested in a capped-length subgroup meeting series, e.g. six months tied to outcomes, but is wary of scope drift. Adrian would like to see an implementation group continue, but he's wondering where the academic focus went. Eve described the 2015 mission http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative/UMA/2013/2.md as relentlessly practical. Mark noted that with the consent receipt work pushing forward, the direction of this work and further collaboration seem very important.

Eve will propose a fresh, limited draft charter for the subgroup.

Eve will schedule a meeting on Friday January 8 for us to review where we are for the first half of 2016.

*Review the first draft deliverable and its model clauses and definitions*

*Intro first para:* We suggest Jim and Scott follow up to switch to "represent" language vs. declaration and conformance (only "operators" can conform, vs. "users").

*Does the color marking system work?* Andrew suggests that color coding doesn't help for tokens. But for defined terms and abbreviations, it does, and probably for the persons/parties.

*Idea for the UX:* It would be cool if clicking on a term/abbreviation would take the reader to the definition.

*What to do about Individual/NPE/Subject?* In the era of IoT, we have to get this very right. The alternative that would be both legal- and technical-friendly would be *Individual *(?)*/Legal Person/* Device/Application/etc.*/Person*.

Note that Subject in a legal sense is much more than "subject" in a technical sense; the former is the "subject of someone's gaze" (think data subject) and the latter, at least in security and identity is the subject of authentication. Also, we'll need conversion tables into other natural languages.

Can we define the terms as bounded by US law until we can vet that it works cross-jurisdictionally, or provide sets of terms that are compatible with different jurisdictions? If we're targeting Canada as a first "customer", how should we handle this? Maybe we can put a note into the relevant definitions, we can put in notes about these being derived from US law.

Can we borrow/steal from some existing federation language to support our UMA-specific needs? The UETA may have everything we need to support both "bags of protoplasm" and "organizations" running "server-side services" and "client-side apps".

Jim will propose a change to this set of terms, with Legal Person (without an abbreviation). We may someday use NPE for equipment.

*Two-party or three-party relationships?* We can see three-party relationships we clustering of two-party relationships, where a condition precedent to one two-party relationship is the formation of a prior two-party relationship. We can state any condition precedent and/or condition subsequent in terms of UMA roles (and leave holes for non-UMA conditions).

AI: Jim/Eve: We'll have to be sure to do that in our clause reusability structuring.

Scott notes that there's an RNA analogy. And Dazza notes that the Carat Guidelines from the '90s (here http://civics.typepad.com/files/carat_final_011400-1.pdf) said that there should be a limited number of roles, functions are allocated to roles, and when there are permutations and functions are allocated to more than one legal party, it should be clear what rights and obligations are delegated to them and which are delegable and non-delegable.

Maybe we can include some of that language!

*Adrian's earlier comments:* In email, Adrian sent comments that pointed out a typo we will fix.

*Analyzing the very first clause:* "When the Client successfully gains access from a Resource Server to a protected resource by wielding a valid "bearer" RPT associated with at least one currently valid permission for the type of access sought, the Requesting Party using that Client gains an obligation to the Authorizing Party to adhere to any terms it agreed to in order to gain the permission." We drilled down into the specific Adhere-to-Terms clause source http://www.commonaccord.org/index.php?action=source&file=GHx/KantaraInitiative/UMA/2013/2_2_1.md, which has "comments" and "issues" that don't show up in the main document rendering.

Eve observes that:

- A LOT of conditions precedent seem to be buried in that one condition! - We probably need to get into the weeds of the Client Operator in a way we haven't previously. - We haven't said that the Requesting Party actually supplied claims, and maybe this Duty should only depend on a Condition of having supplied claims; the Issue mentions that the Condition perhaps be at the juncture of supplying the claim. - And oh, by the way, this clause is just stating the "blinding flash of the obvious" about what the protocol messages *exist to mean*. SAML the protocol never ever stated this: An IdP never promises to mean that it authenticated somebody at time *x* using method *y*.

Scott observes that:

- Right. Sit down in the chair -- get a haircut -- you have to pay for it. :-)

Dazza observes that:

- We have to get into "all applicable laws need to be followed". - We can start to have everyone propose clauses for our "clause bank", now that we are hammering out the canonical form.

Jim observes that:

- We can actually have a series of "Duty" phrases that can appear as alternatives and/or can aggregate. This would be a different reusability logic vs. the Adhere-to-Terms unique naming of each Duty, and would depend on whether the Condition is unique per set of Duty phrases.

Jim and Eve: Propose a fresh clause skeleton http://www.commonaccord.org/index.php?action=source&file=GHx/KantaraInitiative/UMA/Z/Clause.md .

*Thanks to all, with especial thanks to Jim and Mark! See you on the other side!*

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

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

Give_Accurate_Access is struck. (one separate git commit). Also set up the Duty in each Clause for multiple solutions. Did this by replacing: Duty=some text with: Duty={Duty.1} Duty.1=some text This allows a: Duty.2=some other text Mouse-over shows that it is Duty.1, etc. This permits curation of a number of alternatives (the number can be big). It is also possible to add to the list of possible Duties by referencing other files. If this looks good, I can do the same for the Conditions. On Tue, Dec 22, 2015 at 3:12 AM, Eve Maler wrote:

...and in sorting out Allan's comment from Skype, I realized that the problem is in here:

http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Clause/RSO/0.md

The Give_Accurate_Access clause should simply be struck as inappropriate. (If you drill down into it, you'll see that we contemplated striking it a long time ago; the text in Core Sec 3.3.3 in UMA V1.0.1 about the RS reserving the right to perform its own authorization processes is what supports the removal.) I had deleted it from /2013/02, or thought I had, but it came back.

Thank you!

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Dec 21, 2015 at 5:58 PM, Eve Maler wrote:

...

Jim-- Great job on the refactoring! I'm finally getting a chance to take a quick look. Individual/Legal Person/Person looks good.

What do you think about building into the clause skeleton the idea of having potentially multiple "conditions precedent" and "conditions subsequent" as Scott suggested, and multiple "duties" (perhaps with, typically, only one duty defined by us out of the gate)? It may be that bulleted lists will therefore be our friend in terms of standard formatting, and phrases (actually clauses in English grammar, but now that's confusing to say!) with sentential initial caps will be the easiest all around.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Sun, Dec 20, 2015 at 2:37 AM, James Hazard wrote:

...

Scott -

Following up on the discussion, changes to the Introduction can be made here. Paste a copy of the changed text (or, better, just the lines you change) in an email and send to me. The site is just a presentation of the GitHub repo and changes need to be made at the repo. If you have a GitHub account, you can make the changes there (link at the top) and do a pull request.

Jim

http://www.commonaccord.org/index.php?action=edit&file=GH/KantaraInitiative/UMA-Text/Comment/Introduction_0.md

On Sat, Dec 19, 2015 at 7:22 PM, James Hazard wrote:

...

Very briefly (almost dinner time here) - a refactoring, at:

http://www.commonaccord.org/index.php?action=doc&file=GH/KantaraInitiative/UMA-Text/0.md

Most of the modules have meaningful names and are organized into folders. (click on source and follow links). The defined terms link to the definitions (per suggestion yesterday).

I made many imperial decisions about naming conventions. Most have some thought built in but also have an element of arbitrary, and there are undoubtedly other thoughts they could reflect.

Best, Jim

On Fri, Dec 18, 2015 at 6:37 PM, Eve Maler wrote:

...

- Review the first draft deliverable http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative/UMA/2013/2.md and its model clauses and definitions - How to take our work forward? Continue our subgroup meetings? - AOB

Attending: Eve, Andrew H, Steve, Adrian, John W, Mark, Ann, Jon N, Jim, Scott, Dazza

*How to take our work forward? Continue our subgroup meetings?*

What is the interest in continuing the subgroup meeting series into 2016? Andrew is interested in a capped-length subgroup meeting series, e.g. six months tied to outcomes, but is wary of scope drift. Adrian would like to see an implementation group continue, but he's wondering where the academic focus went. Eve described the 2015 mission http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative/UMA/2013/2.md as relentlessly practical. Mark noted that with the consent receipt work pushing forward, the direction of this work and further collaboration seem very important.

Eve will propose a fresh, limited draft charter for the subgroup.

Eve will schedule a meeting on Friday January 8 for us to review where we are for the first half of 2016.

*Review the first draft deliverable and its model clauses and definitions*

*Intro first para:* We suggest Jim and Scott follow up to switch to "represent" language vs. declaration and conformance (only "operators" can conform, vs. "users").

*Does the color marking system work?* Andrew suggests that color coding doesn't help for tokens. But for defined terms and abbreviations, it does, and probably for the persons/parties.

*Idea for the UX:* It would be cool if clicking on a term/abbreviation would take the reader to the definition.

*What to do about Individual/NPE/Subject?* In the era of IoT, we have to get this very right. The alternative that would be both legal- and technical-friendly would be *Individual *(?)*/Legal Person/* Device/Application/etc.*/Person*.

Note that Subject in a legal sense is much more than "subject" in a technical sense; the former is the "subject of someone's gaze" (think data subject) and the latter, at least in security and identity is the subject of authentication. Also, we'll need conversion tables into other natural languages.

Can we define the terms as bounded by US law until we can vet that it works cross-jurisdictionally, or provide sets of terms that are compatible with different jurisdictions? If we're targeting Canada as a first "customer", how should we handle this? Maybe we can put a note into the relevant definitions, we can put in notes about these being derived from US law.

Can we borrow/steal from some existing federation language to support our UMA-specific needs? The UETA may have everything we need to support both "bags of protoplasm" and "organizations" running "server-side services" and "client-side apps".

Jim will propose a change to this set of terms, with Legal Person (without an abbreviation). We may someday use NPE for equipment.

*Two-party or three-party relationships?* We can see three-party relationships we clustering of two-party relationships, where a condition precedent to one two-party relationship is the formation of a prior two-party relationship. We can state any condition precedent and/or condition subsequent in terms of UMA roles (and leave holes for non-UMA conditions).

AI: Jim/Eve: We'll have to be sure to do that in our clause reusability structuring.

Scott notes that there's an RNA analogy. And Dazza notes that the Carat Guidelines from the '90s (here http://civics.typepad.com/files/carat_final_011400-1.pdf) said that there should be a limited number of roles, functions are allocated to roles, and when there are permutations and functions are allocated to more than one legal party, it should be clear what rights and obligations are delegated to them and which are delegable and non-delegable.

Maybe we can include some of that language!

*Adrian's earlier comments:* In email, Adrian sent comments that pointed out a typo we will fix.

*Analyzing the very first clause:* "When the Client successfully gains access from a Resource Server to a protected resource by wielding a valid "bearer" RPT associated with at least one currently valid permission for the type of access sought, the Requesting Party using that Client gains an obligation to the Authorizing Party to adhere to any terms it agreed to in order to gain the permission." We drilled down into the specific Adhere-to-Terms clause source http://www.commonaccord.org/index.php?action=source&file=GHx/KantaraInitiative/UMA/2013/2_2_1.md, which has "comments" and "issues" that don't show up in the main document rendering.

Eve observes that:

- A LOT of conditions precedent seem to be buried in that one condition! - We probably need to get into the weeds of the Client Operator in a way we haven't previously. - We haven't said that the Requesting Party actually supplied claims, and maybe this Duty should only depend on a Condition of having supplied claims; the Issue mentions that the Condition perhaps be at the juncture of supplying the claim. - And oh, by the way, this clause is just stating the "blinding flash of the obvious" about what the protocol messages *exist to mean*. SAML the protocol never ever stated this: An IdP never promises to mean that it authenticated somebody at time *x* using method *y*.

Scott observes that:

- Right. Sit down in the chair -- get a haircut -- you have to pay for it. :-)

Dazza observes that:

- We have to get into "all applicable laws need to be followed". - We can start to have everyone propose clauses for our "clause bank", now that we are hammering out the canonical form.

Jim observes that:

- We can actually have a series of "Duty" phrases that can appear as alternatives and/or can aggregate. This would be a different reusability logic vs. the Adhere-to-Terms unique naming of each Duty, and would depend on whether the Condition is unique per set of Duty phrases.

Jim and Eve: Propose a fresh clause skeleton http://www.commonaccord.org/index.php?action=source&file=GHx/KantaraInitiative/UMA/Z/Clause.md .

*Thanks to all, with especial thanks to Jim and Mark! See you on the other side!*

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

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

Semantic names are as easy as numbers, but they have to mean something, so to speak. Meaning may need to be earned. At the moment, I suppose each of these Duty.1 could become a Duty.Base, but does that add anything? And what would be the name of the next one, particularly if it is just a fix or fiddle on .Base. Is it the new Base, or do we look for some distinguishing phrase .... ? Of course you can do both, such that Duty.Base={Duty.1-03} or whatever. My hunch is to use version numbers until some meaning cries out. Any of these is easy to do, so LMK. Of course, we could start naming them after cats or mountains. I could refactor the files to clarify the RqP.ASO.* structure. So, as there is now a file for RqP's obligations and separate files for each one of those obligations, there could be an intermediate level collecting RpP's obligation to ASO. This would not change the naming scheme since there is already a notion of FromWhom.ToWhom.Name-of-the-Duty.Sec, but will provide a collecting place for each From-To pair. At the moment there are only a few instances of multiple duties to the same pair, but logically, it makes sense that there should be this intermediate level. LMK. On Tue, Dec 22, 2015 at 7:02 PM, Eve Maler wrote:

I like semantic naming, that is, giving "nicknames" to the duties same as we do for the overall clauses. Does this make sense to try and do? Once we break out the conditions precedent, however, it may be that there's typically only one duty that matches all the particulars of those those conditions...

Once I survive past Thursday, I will have lots of time to work on this through New Year. :-)

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Tue, Dec 22, 2015 at 12:55 AM, James Hazard wrote:

...

Give_Accurate_Access is struck. (one separate git commit).

Also set up the Duty in each Clause for multiple solutions. Did this by replacing:

Duty=some text

with:

Duty={Duty.1}

Duty.1=some text

This allows a:

Duty.2=some other text

Mouse-over shows that it is Duty.1, etc.

This permits curation of a number of alternatives (the number can be big). It is also possible to add to the list of possible Duties by referencing other files.

If this looks good, I can do the same for the Conditions.

On Tue, Dec 22, 2015 at 3:12 AM, Eve Maler wrote:

...

...and in sorting out Allan's comment from Skype, I realized that the problem is in here:

http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Clause/RSO/0.md

The Give_Accurate_Access clause should simply be struck as inappropriate. (If you drill down into it, you'll see that we contemplated striking it a long time ago; the text in Core Sec 3.3.3 in UMA V1.0.1 about the RS reserving the right to perform its own authorization processes is what supports the removal.) I had deleted it from /2013/02, or thought I had, but it came back.

Thank you!

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Dec 21, 2015 at 5:58 PM, Eve Maler wrote:

...

Jim-- Great job on the refactoring! I'm finally getting a chance to take a quick look. Individual/Legal Person/Person looks good.

What do you think about building into the clause skeleton the idea of having potentially multiple "conditions precedent" and "conditions subsequent" as Scott suggested, and multiple "duties" (perhaps with, typically, only one duty defined by us out of the gate)? It may be that bulleted lists will therefore be our friend in terms of standard formatting, and phrases (actually clauses in English grammar, but now that's confusing to say!) with sentential initial caps will be the easiest all around.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Sun, Dec 20, 2015 at 2:37 AM, James Hazard wrote:

...

Scott -

Following up on the discussion, changes to the Introduction can be made here. Paste a copy of the changed text (or, better, just the lines you change) in an email and send to me. The site is just a presentation of the GitHub repo and changes need to be made at the repo. If you have a GitHub account, you can make the changes there (link at the top) and do a pull request.

Jim

http://www.commonaccord.org/index.php?action=edit&file=GH/KantaraInitiative/UMA-Text/Comment/Introduction_0.md

On Sat, Dec 19, 2015 at 7:22 PM, James Hazard wrote:

...

Very briefly (almost dinner time here) - a refactoring, at:

http://www.commonaccord.org/index.php?action=doc&file=GH/KantaraInitiative/UMA-Text/0.md

Most of the modules have meaningful names and are organized into folders. (click on source and follow links). The defined terms link to the definitions (per suggestion yesterday).

I made many imperial decisions about naming conventions. Most have some thought built in but also have an element of arbitrary, and there are undoubtedly other thoughts they could reflect.

Best, Jim

On Fri, Dec 18, 2015 at 6:37 PM, Eve Maler wrote:

> > > - Review the first draft deliverable > http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative/UMA/2013/2.md and > its model clauses and definitions > - How to take our work forward? Continue our subgroup meetings? > - AOB > > Attending: Eve, Andrew H, Steve, Adrian, John W, Mark, Ann, Jon N, > Jim, Scott, Dazza > > *How to take our work forward? Continue our subgroup meetings?* > > What is the interest in continuing the subgroup meeting series into > 2016? Andrew is interested in a capped-length subgroup meeting series, e.g. > six months tied to outcomes, but is wary of scope drift. Adrian would like > to see an implementation group continue, but he's wondering where the > academic focus went. Eve described the 2015 mission > http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative/UMA/2013/2.md > as relentlessly practical. Mark noted that with the consent receipt work > pushing forward, the direction of this work and further collaboration seem > very important. > > Eve will propose a fresh, limited draft charter for the subgroup. > > Eve will schedule a meeting on Friday January 8 for us to review > where we are for the first half of 2016. > > *Review the first draft deliverable and its model clauses and > definitions* > > *Intro first para:* We suggest Jim and Scott follow up to switch to > "represent" language vs. declaration and conformance (only "operators" can > conform, vs. "users"). > > *Does the color marking system work?* Andrew suggests that color > coding doesn't help for tokens. But for defined terms and abbreviations, it > does, and probably for the persons/parties. > > *Idea for the UX:* It would be cool if clicking on a > term/abbreviation would take the reader to the definition. > > *What to do about Individual/NPE/Subject?* In the era of IoT, we > have to get this very right. The alternative that would be both legal- and > technical-friendly would be *Individual *(?)*/Legal Person/* > Device/Application/etc.*/Person*. > > Note that Subject in a legal sense is much more than "subject" in a > technical sense; the former is the "subject of someone's gaze" (think data > subject) and the latter, at least in security and identity is the subject > of authentication. Also, we'll need conversion tables into other natural > languages. > > Can we define the terms as bounded by US law until we can vet that > it works cross-jurisdictionally, or provide sets of terms that are > compatible with different jurisdictions? If we're targeting Canada as a > first "customer", how should we handle this? Maybe we can put a note into > the relevant definitions, we can put in notes about these being derived > from US law. > > Can we borrow/steal from some existing federation language to > support our UMA-specific needs? The UETA may have everything we need to > support both "bags of protoplasm" and "organizations" running "server-side > services" and "client-side apps". > > Jim will propose a change to this set of terms, with Legal Person > (without an abbreviation). We may someday use NPE for equipment. > > *Two-party or three-party relationships?* We can see three-party > relationships we clustering of two-party relationships, where a condition > precedent to one two-party relationship is the formation of a prior > two-party relationship. We can state any condition precedent and/or > condition subsequent in terms of UMA roles (and leave holes for non-UMA > conditions). > > AI: Jim/Eve: We'll have to be sure to do that in our clause > reusability structuring. > > Scott notes that there's an RNA analogy. And Dazza notes that the > Carat Guidelines from the '90s (here > http://civics.typepad.com/files/carat_final_011400-1.pdf) said > that there should be a limited number of roles, functions are allocated to > roles, and when there are permutations and functions are allocated to more > than one legal party, it should be clear what rights and obligations are > delegated to them and which are delegable and non-delegable. > > Maybe we can include some of that language! > > *Adrian's earlier comments:* In email, Adrian sent comments that > pointed out a typo we will fix. > > *Analyzing the very first clause:* "When the Client successfully > gains access from a Resource Server to a protected resource by wielding a > valid "bearer" RPT associated with at least one currently valid permission > for the type of access sought, the Requesting Party using that Client gains > an obligation to the Authorizing Party to adhere to any terms it agreed to > in order to gain the permission." We drilled down into the specific > Adhere-to-Terms clause source > http://www.commonaccord.org/index.php?action=source&file=GHx/KantaraInitiative/UMA/2013/2_2_1.md, > which has "comments" and "issues" that don't show up in the main document > rendering. > > Eve observes that: > > - A LOT of conditions precedent seem to be buried in that one > condition! > - We probably need to get into the weeds of the Client Operator > in a way we haven't previously. > - We haven't said that the Requesting Party actually supplied > claims, and maybe this Duty should only depend on a Condition of having > supplied claims; the Issue mentions that the Condition perhaps be at the > juncture of supplying the claim. > - And oh, by the way, this clause is just stating the "blinding > flash of the obvious" about what the protocol messages *exist to > mean*. SAML the protocol never ever stated this: An IdP never > promises to mean that it authenticated somebody at time *x* > using method *y*. > > Scott observes that: > > - Right. Sit down in the chair -- get a haircut -- you have to > pay for it. :-) > > Dazza observes that: > > - We have to get into "all applicable laws need to be followed". > - We can start to have everyone propose clauses for our "clause > bank", now that we are hammering out the canonical form. > > Jim observes that: > > - We can actually have a series of "Duty" phrases that can > appear as alternatives and/or can aggregate. This would be a different > reusability logic vs. the Adhere-to-Terms unique naming of each Duty, and > would depend on whether the Condition is unique per set of Duty phrases. > > Jim and Eve: Propose a fresh clause skeleton > http://www.commonaccord.org/index.php?action=source&file=GHx/KantaraInitiative/UMA/Z/Clause.md > . > > *Thanks to all, with especial thanks to Jim and Mark! See you on the > other side!* > > > > *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl > > > _______________________________________________ > WG-UMA mailing list > WG-UMA@kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma > >