OCM/OCM-MLS: Standardize on base64url

IETF-OCM-MLS.md

@@ -137,6 +137,12 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as
 shown here.
 
+Unless stated otherwise, every base64 encoded value this document,
+including MLS wire-format messages, KeyPackages, `group_id` values, and
+wrapped keys, is encoded using base64url (the URL- and filename-safe
+alphabet defined in [RFC4648], Section 5) with padding omitted.  A
+decoder MUST accept such a value whether or not padding is present.
+
 This document uses terminology from [OCM] and [RFC9420].  Additional
 definitions:
 
@@ -402,8 +408,8 @@ Response:
   "keyPackages": [
     {
       "mediaType": "message/mls",
-      "encoding": "base64",
-      "content": "<base64-encoded MLS KeyPackage>"
+      "encoding": "base64url",
+      "content": "<base64url-encoded MLS KeyPackage>"
     }
   ]
 }
@@ -671,7 +677,7 @@ that requirement: `providerId` is REQUIRED only for notification types
 that refer to a Share, and the MLS notification types omit it.  All
 MLS-specific parameters are carried inside the `notification` object
 that [OCM] provides for type-specific parameters.  The `mlsGroupId`
-field carries the base64-encoded MLS `group_id` as advisory routing
+field carries the base64url-encoded MLS `group_id` as advisory routing
 information, used to dispatch the message to the right group state
 without parsing the MLS message; the authoritative `group_id` is the one
 inside the MLS message itself, and a mismatch between the two MUST be
@@ -704,9 +710,9 @@ added user.
 {
   "notificationType": "MLS_WELCOME",
   "notification": {
-    "mlsGroupId": "<base64 MLS group ID>",
+    "mlsGroupId": "<base64url MLS group ID>",
     "userId": "bob@othercloud.example.org",
-    "content": "<base64 MLS Welcome wire format>"
+    "content": "<base64url MLS Welcome wire format>"
   }
 }
 ~~~
@@ -744,8 +750,8 @@ act on it.
 {
   "notificationType": "MLS_PROPOSAL",
   "notification": {
-    "mlsGroupId": "<base64 MLS group ID>",
-    "content": "<base64 MLS PublicMessage carrying the Proposal>"
+    "mlsGroupId": "<base64url MLS group ID>",
+    "content": "<base64url MLS PublicMessage carrying the Proposal>"
   }
 }
 ~~~
@@ -772,9 +778,9 @@ data, per [RFC9420] Section 15.2.
 {
   "notificationType": "MLS_COMMIT",
   "notification": {
-    "mlsGroupId": "<base64 MLS group ID>",
-    "proposals": ["<base64 MLS PublicMessage carrying a Proposal>"],
-    "content": "<base64 MLS PublicMessage carrying the Commit>"
+    "mlsGroupId": "<base64url MLS group ID>",
+    "proposals": ["<base64url MLS PublicMessage carrying a Proposal>"],
+    "content": "<base64url MLS PublicMessage carrying the Commit>"
   }
 }
 ~~~
@@ -818,8 +824,8 @@ epoch ([RFC9420] Section 15).
 {
   "notificationType": "MLS_APPLICATION",
   "notification": {
-    "mlsGroupId": "<base64 MLS group ID>",
-    "content": "<base64 MLS PrivateMessage wire format>"
+    "mlsGroupId": "<base64url MLS group ID>",
+    "content": "<base64url MLS PrivateMessage wire format>"
   }
 }
 ~~~
@@ -859,13 +865,13 @@ by the KeyPackage endpoint.
 {
   "notificationType": "MLS_REJOIN",
   "notification": {
-    "mlsGroupId": "<base64 MLS group ID>",
+    "mlsGroupId": "<base64url MLS group ID>",
     "keyPackages": [
       {
         "userId": "bob@othercloud.example.org",
         "mediaType": "message/mls",
-        "encoding": "base64",
-        "content": "<base64-encoded MLS KeyPackage>"
+        "encoding": "base64url",
+        "content": "<base64url-encoded MLS KeyPackage>"
       }
     ]
   }
@@ -1169,7 +1175,7 @@ array, and MAY also carry a `credentials` array ({{credential-update}}):
     {
       "resourceId": "3a02538b-aa54-42f2-8853-a38996e211b1",
       "groupId": "research-group@receiver.example.org",
-      "wrappedKey": "<base64 nonce || wrapped_file_key || tag>"
+      "wrappedKey": "<base64url nonce || wrapped_file_key || tag>"
     }
   ]
 }
@@ -1916,6 +1922,10 @@ Work in Progress, Internet-Draft.
 Requirement Levels](https://datatracker.ietf.org/doc/html/rfc2119)",
 March 1997.
 
+[RFC4648] Josefsson, S.  "[The Base16, Base32, and Base64 Data
+Encodings](https://datatracker.ietf.org/doc/html/rfc4648)", October
+2006.
+
 [RFC7517] Jones, M., "[JSON Web Key
 (JWK)](https://datatracker.ietf.org/doc/html/rfc7517)", May 2015.
 

IETF-OCM.md

@@ -124,8 +124,10 @@ related concepts from OAuth [RFC6749] and elsewhere:
 * __Invite Sender OCM Server__ - The server holding an address book
   used by the Invite Sender, to which details of the Invite Receiver are
   to be added.
-* __Invite String__ - A base64 encoded string containing an Invite Token
-  and the FQDN of an Invite Sender OCM Server joined by an `@`-sign.
+* __Invite String__ - An Invite Token and the FQDN of an Invite Sender
+  OCM Server joined by an `@`-sign, then encoded using base64url (the
+  URL- and filename-safe alphabet defined in [RFC4648], Section 5) with
+  padding omitted.
 * __Invite Token__ - A hard-to-guess string used in the Invite Flow,
   generated by the Invite Sender OCM Server and linked uniquely to the
   Invite Sender's OCM Address.
@@ -472,19 +474,21 @@ To accept an invite, two pieces of information are required: a `token`
 and a `provider`.  There are two recognized formats:
 
 * **Invite string format:**
-  A base64-encoded string containing the token and the provider’s FQDN,
-  joined by an `@` sign.  Example:
+  The token and the provider’s FQDN, joined by an `@` sign and then
+  encoded using base64url (the URL- and filename-safe alphabet defined
+  in [RFC4648], Section 5) with padding omitted.  Example:
 
   If the `token` is `a55a966e-15c1-4cb9-a39d-4e4c54399baf` and the
   `provider` is `cloud.example.org`, the combined string is
   `a55a966e-15c1-4cb9-a39d-4e4c54399baf@cloud.example.org`,
-  which when base64-encoded becomes
-  `YTU1YTk2NmUtMTVjMS00Y2I5LWEzOWQtNGU0YzU0Mzk5YmFmQG15LWNsb3VkLXN0b
-  3JhZ2Uub3Jn`.
+  which when base64url-encoded becomes
+  `YTU1YTk2NmUtMTVjMS00Y2I5LWEzOWQtNGU0YzU0Mzk5YmFmQGNsb3VkLmV4YW1wbGUu
+  b3Jn`.
 
-  When parsing an invite string, implementors must base64-decode it,
-  then split on the last `@` sign, taking care to allow multiple `@`
-  characters in the token part.
+  When parsing an invite string, implementors MUST base64url-decode it
+  (accepting the string whether or not padding is present), then split
+  on the last `@` sign, taking care to allow multiple `@` characters in
+  the token part.
 
 * **Link format:**
   If the inviting OCM Server supports a WAYF page, the invite may be
@@ -1734,6 +1738,10 @@ March 1997.
 "[Uniform Resource Identifier (URI): Generic Syntax
 ](https://datatracker.ietf.org/doc/html/rfc3986)", January 2005
 
+[RFC4648] Josefsson, S. "[The Base16, Base32, and Base64 Data
+Encodings](https://datatracker.ietf.org/doc/html/rfc4648)", October
+2006.
+
 [RFC4918] Dusseault, L. M. "[HTTP Extensions for Web Distributed
 Authoring and Versioning](https://datatracker.ietf.org/html/rfc4918/)",
 June 2007.
@@ -1777,13 +1785,13 @@ https://datatracker.ietf.org/doc/html/rfc9553), May 2024"
 
 ## Informative References
 
-[OCM-IP] Nordin, M., Lo Presti, G., and Baghbani, M. "[Open
-Cloud Mesh Integration
+[OCM-IP] Nordin, M., Lo Presti, G., and Baghbani, M. "[Open Cloud Mesh
+Integration
 Protocol](https://datatracker.ietf.org/doc/draft-nordin-ocm-integration-protocol/)",
 Work in Progress, Internet-Draft.
 
-[OCM-MLS] Nordin, M., Lo Presti, G., and Baghbani, M. "[Federated
-Groups in Open Cloud Mesh using Messaging Layer
+[OCM-MLS] Nordin, M., Lo Presti, G., and Baghbani, M. "[Federated Groups
+in Open Cloud Mesh using Messaging Layer
 Security](https://datatracker.ietf.org/doc/draft-nordin-ocm-mls-federated-groups/)",
 Work in Progress, Internet-Draft.
 

diagrams/invitation-flow.md

@@ -31,7 +31,7 @@ sequenceDiagram
     alt
         HTTPA ->> UserB: Send Email with Alice's Server FQDN and Token
     else
-        HTTPA ->> UserA: Raw or Base64 encoded "token@FQDN"
+        HTTPA ->> UserA: Raw or base64url encoded "token@FQDN"
         UserA ->> UserB: Aice passes token to Bob
     end