Skip to content

Commit 7a531d8

Browse files
genwhittTTDgenwhittTTD
committed
edits from SW with samples of different table treatments
1 parent c05af9e commit 7a531d8

File tree

1 file changed

+92
-2
lines changed

1 file changed

+92
-2
lines changed

‎docs/getting-started/gs-normalization-encoding.md‎

Lines changed: 92 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -58,7 +58,7 @@ For examples of various scenarios, see [Normalization Examples for Email](#norma
5858

5959
An email hash is a Base64-encoded <Link href="../ref-info/glossary-uid#gl-sha-256">SHA-256</Link> hash of a normalized email address. The email address is first normalized, then hashed using the SHA-256 hashing algorithm, and then the resulting bytes of the hash value are encoded using Base64 encoding. Note that the Base64 encoding is applied to the bytes of the hash value, not the hex-encoded string representation.
6060

61-
The following table shows an example of a simple input email address, and the result as each step is applied to arrive at a secure, opaque, URL-safe value.
61+
The following table shows an example of a simple input email address, and the result as each step is applied to arrive at a secure, opaque value.
6262

6363
The final value, the hex to Base64 encoded representation of the SHA-256 hash, is the value to provide to the UID2 Operator endpoint.
6464

@@ -85,6 +85,96 @@ Some of the examples show email addresses that include the plus sign (+), with d
8585
In working with your own UID2s, always provide the final value, the Base64-encoded value, to the UID2 Operator endpoint.
8686
:::
8787

88+
[**GWH__SW Not entirely sure what you're asking, but, trying a couple of different treatments here. Below is #1. I'd tried this before the one I checked in, but felt there was too much separation between the values.**]
89+
90+
<table>
91+
<thead>
92+
<tr>
93+
<th>Original Value</th>
94+
<th>Processing Steps</th>
95+
<th>Resulting Values</th>
96+
</tr>
97+
</thead>
98+
<tbody>
99+
<tr>
100+
<td rowspan="3">`[email protected]`</td>
101+
<td>1. Normalize</td>
102+
<td>`[email protected]`</td>
103+
</tr>
104+
<tr>
105+
106+
<td>2. Hash</td>
107+
<td>`16c18d336f0b250f0e2d907452ceb9658a74ecdae8bc94864c23122a72cc27a5`</td>
108+
</tr>
109+
<tr>
110+
111+
<td>3. Base64-Encode</td>
112+
<td>`FsGNM28LJQ8OLZB0Us65ZYp07NrovJSGTCMSKnLMJ6U=`</td>
113+
</tr>
114+
<tr>
115+
<td rowspan="3">`[email protected]`<br/>`[email protected]`</td>
116+
<td>1. Normalize</td>
117+
<td>`[email protected]`</td>
118+
</tr>
119+
<tr>
120+
121+
<td>2. Hash</td>
122+
<td>`16c18d336f0b250f0e2d907452ceb9658a74ecdae8bc94864c23122a72cc27a5`</td>
123+
</tr>
124+
<tr>
125+
126+
<td>3. Base64-Encode</td>
127+
<td>`4itTvG+HEnTzpiqzejyu1yFPwU1nYhWpaiQvz62hyB8=`</td>
128+
</tr>
129+
<tr>
130+
<td rowspan="3">`[email protected]`</td>
131+
<td>1. Normalize</td>
132+
<td>`[email protected]`</td>
133+
</tr>
134+
<tr>
135+
136+
<td>2. Hash</td>
137+
<td>`e22b53bc6f871274f3a62ab37a3caed7214fc14d676215a96a242fcfada1c81f`</td>
138+
</tr>
139+
<tr>
140+
141+
<td>3. Base64-Encode</td>
142+
<td>`4itTvG+HEnTzpiqzejyu1yFPwU1nYhWpaiQvz62hyB8=`</td>
143+
</tr>
144+
</tbody>
145+
</table>
146+
147+
148+
[**GWH__SW here is another. If you don't like either of these, let's discuss in our meeting my Tues your Wed. Note: I could add space between the steps and values, but don't have a way to align them, AFAIK, with our current CSS.But, the above example has the values in separate rows, and the below example combines them. I felt that separate rows were too spread out; but if you feel that combining them is too squashed or otherwise less readable, we can have separate rows of course.**]
149+
150+
151+
<table>
152+
<thead>
153+
<tr>
154+
<th>Original Value</th>
155+
<th>Processing Steps and Resulting Values</th>
156+
</tr>
157+
</thead>
158+
<tbody>
159+
<tr>
160+
<td>`[email protected]`<br/>`[email protected]`</td>
161+
<td>1. Normalize: `[email protected]`<br/>2. Hash: `16c18d336f0b250f0e2d907452ceb9658a74ecdae8bc94864c23122a72cc27a5`<br/>3. Base64-Encode: `FsGNM28LJQ8OLZB0Us65ZYp07NrovJSGTCMSKnLMJ6U=`</td>
162+
</tr>
163+
<tr>
164+
<td>`[email protected]`<br/>`[email protected]`</td>
165+
<td>1. Normalize: `[email protected]`<br/>2. Hash: `16c18d336f0b250f0e2d907452ceb9658a74ecdae8bc94864c23122a72cc27a5`<br/>3. Base64-Encode: `FsGNM28LJQ8OLZB0Us65ZYp07NrovJSGTCMSKnLMJ6U=`</td>
166+
</tr>
167+
<tr>
168+
<td>`[email protected]`</td>
169+
<td>1. Normalize: `[email protected]`<br/>2. Hash: `e22b53bc6f871274f3a62ab37a3caed7214fc14d676215a96a242fcfada1c81f`<br/>3. Base64-Encode: `4itTvG+HEnTzpiqzejyu1yFPwU1nYhWpaiQvz62hyB8=`</td>
170+
</tr>
171+
</tbody>
172+
</table>
173+
174+
175+
[**GWH__SW here is the table I checked in, for comparison**]
176+
177+
88178
<table>
89179
<thead>
90180
<tr>
@@ -166,7 +256,7 @@ Make sure that the normalized phone number is UTF-8, not another encoding system
166256

167257
A phone number hash is a Base64-encoded SHA-256 hash of a normalized phone number. The phone number is first normalized, then hashed using the SHA-256 hashing algorithm, and then the resulting bytes of the hash value are encoded using Base64 encoding. Note that the Base64 encoding is applied to the bytes of the hash value, not the hex-encoded string representation.
168258

169-
The following table shows an example of a simple input phone number, and the result as each step is applied to arrive at a secure, opaque, URL-safe value.
259+
The following table shows an example of a simple input phone number, and the result as each step is applied to arrive at a secure, opaque value.
170260

171261
The final value, the hex to Base64 encoded representation of the SHA-256 hash, is the value to provide to the UID2 Operator endpoint.
172262

0 commit comments

Comments
 (0)