Ti	=	Introduction
1.sec	=	This document gathers together a series of model clauses representing a minimum set of commitments that parties serving in roles defined by the {UMA} specifications are assumed to adopt.
2.sec	=	The clauses assume the parties are operating and using software programs and services in an environment where the operators declare themselves to be {UMA}-conforming and the parties formally agree (for example, in the form of contracts using these clauses) to such terms.
3.sec	=	To get started, click on the Document link at the top. This will expand all the content from mere references to full values.
4.sec	=	The technical system in which the clauses are encoded is called CommonAccord, which "expresses legal relationships as 'objects,' like software." This allows for reusability of each clause, term, abbreviation, and component therein.
5.sec	=	Terms and abbreviations appearing in the Terminology section are shown in green, persons (in the legal sense) are shown in brown, and tokens (UMA technical artifacts) are shown in red for your reading convenience.
6.0.sec	=	When reading, please note:
6.1.sec	=	All of the formatting chosen here is adjustable, including colors, lists vs. paragraphs, headings, and so on. Suggestions on improving the formatting are welcome.
6.2.sec	=	This summary is intended to be used as just a guide to the available reusable model clauses. We intend shortly to produce multiple sample documents from the exact same "fodder", such as standard agreements with "holes" where non-UMA content could go and consent receipts. Suggestions for sample document prioritization are welcome.
6.3.sec	=	When we like the English version of the UMA-specific content well enough, we intend to produce alternate-language versions as well, targeting French first. Suggestions for language prioritization are welcome.
6.4.sec	=	If you like getting into the bits and bytes of the CommonAccord reusability paradigm, you can click the Source link at the top and then click around on links you find in the document body. To avoid getting lost, you might try right-clicking and opening up links in new tabs or windows.
6.5.sec	=	During live review on the UMA legal subgroup telecon, we will direct your attention to specific individual clauses, wherein you will notice some "Comments" and "Issues" for further discussion.
6.	=	[G/Z/ol-none/s5]
7.0.sec	=	For review purposes, please note the following open issues; if providing comments in email, referencing specific issue item numbers would be helpful:
7.1.Note	=	Reflecting a change in 7.1.sec by renaming the existing one with a version number and replacing it with a new one.
7.1.sec	=	Per the group discussion on 2015-12-18, we now use {Person}, {Individual}, {Legal_Person} to refer to things that the law considers to have capacity to contract. Note that there are variations in this around the world. This also does not deal with the issue of {Individual} under legal incapacity, nor with the authority of a person to sign for a {Legal_Person}. For reference: the ABA Model Share Purchase Agreement.
7.1.sec.01	=	UMA has for some years used (Non-Person Entity} ({Legal_Person}) strictly in a "person" sense, legally speaking. Therefore, we were stuck using {Person} rather than "person". But the term {Legal_Person} comes from the technical world, referring to hardware, servers, and -- on occasion -- organizations (for example, a PKI certificate standing for a whole company). It has been suggested that "Person" would be much more natural than "Subject". So, should we switch? This would have the benefit of freeing up "NPE" for client devices, hardware servers, etc. as well.
7.2.sec	=	The obligations are still phrased as obligations, vs., say, commitments or agreements. Do we feel comfortable with this?
7.3.sec	=	The "conditions" -- "For the period..." and "When..." phrases -- have been revised through Section 3, but need revision and consideration after that point. Are they going in the right direction according to our previous discussions?
7.4.sec	=	All the obligations are between two parties. It is sometimes tempting to put them in the context of three parties. What is most appropriate in forging agreements?
7.5.sec	=	The hardest question: Are these the right obligations? What's missing? How are down the "rabbit hole" of business, legal, and technical obligations should we go? See our recent list discussion about OAuth, SSL, security, liability, and indemnification.
7.	=	[G/Z/ol/s5]
	=	[G/Z/paras/s7]
	=