Merge pull request #71 from IMSGlobal/trademark

Add trademark to Badge Connect

ob_v2p1/LICENSE-INPROGRESS.md

@@ -1,6 +1,6 @@
 # badge-connect-api
 
-This is the repository for the IMS Global Badge Connect API specification.
+This is the repository for the IMS Global Badge Connect™ API specification.
 
 ## In Progress Specification License
 While the specification is under development all materials and draft specifications

ob_v2p1/README.md

@@ -1,5 +1,5 @@
-# Open Badges 2.1 Badge Connect API
-This is the repository for the IMS Global Badge Connect API specification. This specification will be released as Open Badges v2.1.
+# Open Badges 2.1 Badge Connect™ API
+This is the repository for the IMS Global Badge Connect™ API specification. This specification will be released as Open Badges v2.1.
 
 ## Working Group Contact Information
 

ob_v2p1/localBiblio.js

@@ -34,7 +34,7 @@ var _localBiblio = {
         publisher: "IMS Global"
     },
     "OB-JSON-21": {
-        title: "JSON Schema Files for Open Badges Badge Connect API v2.1",
+        title: "JSON Schema Files for Open Badges Badge Connect(TM) API v2.1",
         href: "https://purl.imsglobal.org/spec/ob/v2p1/schema/json/",
         date: "August 29, 2019",
         publisher: "IMS Global",
@@ -56,7 +56,7 @@ var _localBiblio = {
         ]
     },
     "OB-OPEN-21": {
-        title: "OpenAPI 3.0 File for Open Badges Badge Connect API v2.1",
+        title: "OpenAPI 3.0 File for Open Badges Badge Connect(TM) API v2.1",
         href: "https://purl.imsglobal.org/spec/ob/v2p1/schema/openapi/imsob_v2p1.yaml",
         date: "August 29, 2019",
         publisher: "IMS Global",

ob_v2p1/ob-cert-v2p1.html

@@ -70,7 +70,7 @@ <h1>Revision History</h1>
                 <tr>
                     <td>Version 2.1 IMS Candidate Final</td>
                     <td>August 29, 2019</td>
-                    <td>Added Badge Connect API conformance tests.</td>
+                    <td>Added Badge Connect&trade; API conformance tests.</td>
                 </tr>
                 <tr>
                     <td>Version 2.0 IMS Final</td>

ob_v2p1/ob-cert-v2p1.md

@@ -32,7 +32,7 @@ After IMS reviews your submitted information and notifies you that your applicat
 
 ### Issuer Role Conformance
 
-An Open Badges **Issuer** is an application that allows for the creation of <a data-cite="OB-21#BadgeClass">BadgeClasses</a> and the subsequent delivery of <a data-cite="OB-21#Assertion">Assertions</a> to recipients that conform to the [[[OB-21]]]. Beginning with Open Badges 2.1, the candidate platform must support the transimission of a badge using the Badge Connect API.
+An Open Badges **Issuer** is an application that allows for the creation of <a data-cite="OB-21#BadgeClass">BadgeClasses</a> and the subsequent delivery of <a data-cite="OB-21#Assertion">Assertions</a> to recipients that conform to the [[[OB-21]]]. Beginning with Open Badges 2.1, the candidate platform must support the transimission of a badge using the Badge Connect&trade; API.
 
 **Tests**
 
@@ -54,7 +54,7 @@ An Open Badges **Issuer** is an application that allows for the creation of <a d
 
 ### Displayer Role Conformance
 
-An Open Badges **Displayer** is an application that displays verified badges to viewers. Beginning with Open Badges 2.1, the candidate platform must be able to retrieve badges using the Badge Connect API.
+An Open Badges **Displayer** is an application that displays verified badges to viewers. Beginning with Open Badges 2.1, the candidate platform must be able to retrieve badges using the Badge Connect&trade; API.
 
 **Tests**
 
@@ -77,7 +77,7 @@ An Open Badges **Displayer** is an application that displays verified badges to
 
 ### Host Role Conformance
 
-An Open Badges **Host** is an application that can aggregate and publicly host <a data-cite="OB-21#Assertion">Assertions</a> for recipients. It also supports export of badges at user request. Beginning with Open Badges 2.1, the candidate platform must be able to send and receive assertions and profiles using the Badge Connect API.
+An Open Badges **Host** is an application that can aggregate and publicly host <a data-cite="OB-21#Assertion">Assertions</a> for recipients. It also supports export of badges at user request. Beginning with Open Badges 2.1, the candidate platform must be able to send and receive assertions and profiles using the Badge Connect&trade; API.
 
 **Tests**
 

ob_v2p1/ob-spec-v2p1.html

@@ -43,7 +43,7 @@ <h2>Introduction</h2>
 
     <section class="informative">
       <h3>Design Goals and Rationale</h3>
-      <p>Open Badges 2.1 is a specification that adds the Badge Connect API to Open Badges that allows badge recipients
+      <p>Open Badges 2.1 is a specification that adds the Badge Connect&trade; API to Open Badges that allows badge recipients
         to easily move their Assertions between
         platforms to streamline the experience of earning and using Open Badges. The initial scope for this
         specification will cover Assertions and Profiles, with potential additions in future versions of other types of
@@ -97,11 +97,11 @@ <h3>Conformance and Certification</h3>
 
   <section>
     <h2>API</h2>
-    <p>Badge Connect defines a JSON API protocol to be implemented by applications serving in the
+    <p>Badge Connect&trade; defines a JSON API protocol to be implemented by applications serving in the
       roles of Host and Relying Party. Typically Relying Parties SHOULD be certified Open Badges
       services in the Open Badges roles of Displayer or Issuer, though Hosts may also be relying
       parties to serve the <a href="#usecases-host-host-transfer">Host to Host transfer use case</a>.
-      Badge Connect API uses OAuth 2.0 for authentication, granular resource-based permission
+      Badge Connect&trade; API uses OAuth 2.0 for authentication, granular resource-based permission
       scopes, and offers a number of required endpoints that MUST be implemented by Hosts and
       Relying Parties or both.
     </p>
@@ -112,7 +112,7 @@ <h3>Architecture</h3>
         <img src="images/OBC_Architecture.svg" />
         <figcaption>Architecture</figcaption>
       </figure>
-            <p>There are five key components to the Badge Connect API architecture.</p>
+            <p>There are five key components to the Badge Connect&trade; API architecture.</p>
         <dl>
           <dt>Resource Owner</dt>
           <dd>This is the user that owns the resources (badges) that are on the Host.</dd>
@@ -382,7 +382,7 @@ <h3>Obtaining Tokens</h3>
             href="#oauth-registration">Registration</a>,
           the Relying Party then MAY initiate an authorization request as described in Section 4.2
           of the IMS Security Framework [[SEC-10]] by redirecting the user to the Host's authorizationUrl as
-          declared in the Host's Badge Connect <a href="#api-manifest">Manifest</a>.
+          declared in the Host's Badge Connect&trade; <a href="#api-manifest">Manifest</a>.
         </p>
         <figure id="sd-authorization">
           <img src="images/OBC_AuthenticationSequenceDiagram.svg" alt="" />
@@ -475,7 +475,7 @@ <h3>Obtaining Tokens</h3>
 
         <p>With the supplied code, the Relying Party SHOULD attempt to exchange the code for a
           token. The Relying Party makes an authorization grant POST request to the Host's
-          tokenUrl, as declared in the Host's Badge Connect <a href="#api-manifest">Manifest</a>.
+          tokenUrl, as declared in the Host's Badge Connect&trade; <a href="#api-manifest">Manifest</a>.
           The HTTP POST request MUST include a Basic authorization header with the <code>client_id</code>
           and <code>client_secret</code> provided by the response to the registrationUrl endpoint.
           The body of the request MUST include the following form fields:
@@ -567,7 +567,7 @@ <h3>Revocation by Relying Party</h3>
           to implement it, they SHOULD follow [[RFC7009]].</p>
         <h4>Revocation Request</h4>
         <p>The Relying Party makes a POST request to the Host's token revocation URL, as declared in the Host's Badge
-          Connect <a href="#api-manifest">Manifest</a>.
+          Connect&trade; <a href="#api-manifest">Manifest</a>.
           The HTTP request entity-body MUST contain a <code>token</code> parameter containing the refresh token or
           access token.</p>
         <p>Relying Parties MAY also pass a <code>token_type_hint</code> parameter with a value of
@@ -587,11 +587,11 @@ <h4>Revocation Request</h4>
 
     <section id="api-scopes">
       <h3>Scopes</h3>
-      <p>Access to resources in the Badge Connect API require an access token. These access
+      <p>Access to resources in the Badge Connect&trade; API require an access token. These access
         tokens have a permissioned scope when they are created and inform the responding
         application which resources the entity has access to.
       </p>
-      <table title="Scopes for the Badge Connect API endpoints." summary="Scopes for the Badge Connect API endpoints.">
+      <table title="Scopes for the Badge Connect&trade; API endpoints." summary="Scopes for the Badge Connect&trade; API endpoints.">
         <thead>
           <tr>
             <th>Name</th>

ob_v2p1/ob-terms.md

@@ -6,7 +6,7 @@ The following terms are used throughout this document.
 - **Assertion**: A representation of an awarded badge, used to share information about a badge belonging to one recipient.
 - **Backpack**: A term originally used to describe Open Badges services that provide importing, aggregation, and hosting features for recipients. These services match most closely with the role we now define as an Open Badge “Host” application. May also refer to the Mozilla Backpack.
 - **BadgeClass**: A collection of information about the accomplishment recognized by the Open Badge. Many assertions may be created corresponding to one BadgeClass.
-- **BadgeConnectAPI**: Informal name of the RESTful web service for transfering assertions and profiles between systems.
+- **Badge Connect™ API**: Name of the RESTful web service for transfering assertions and profiles between systems.
 - **Badge Issuer**: A service that allows for the creation of BadgeClasses and the subsequent issuing of Assertions to recipients that conform to the Open Badges specification. Beginning with Open Badges 2.0, the candidate platform must issue a valid baked badge and demonstrate how the badge is retrieved by the recipient.
 - **Badge Displayer**: An application that displays verified badges to viewers. Beginning with Open Badges 2.0, the candidate platform must display a minimum set of badge metadata and support viewer-initiated verification of a badge.
 - **Badge Host**: An application that can import, aggregate, and publicly host Assertions for recipients. It also supports export of badges at user request. Beginning with Open Badges 2.0, the candidate platform must be able to import all formats of Open Badges as well as prove that badge metadata is not lost upon export of the badge.
@@ -18,4 +18,4 @@ The following terms are used throughout this document.
 - **Validation and verification (of badge assertions)**: Data validation is a procedure that ensures a cluster of data objects that form an Open Badge are appropriately formatted, published, and linked and that each data object conforms to requirements for its class. Validation of all data class instances used in an Open Badge is a part of badge verification. Verification is the process of ensuring the data that makes up an Open Badge is correct. It includes a number of data validation checks as well as procedures to ensure the badge is trustworthy. Verification is distinct from compliance certification for applications and services that implement the specification, though verification is typically a component of certification programs. See <a href="OB-SPEC-21#Verification">Verification</a> in the current specification.
 
 <div></div>
-`;
+`;