docs: 466/hash-verification #512
Conversation
|
✅ Deploy Preview for openpayments-preview canceled.
|
|
|
||
| import { CodeBlock, LinkOut } from '@interledger/docs-design-system' | ||
|
|
||
| Once a resource owner (RO) authorizes a client software, the authorization server (AS) will redeirect the RO's [identify provider (IdP)](/introduction/idp/) to the finish URI. In order to secure this communication and verify that the redirect indeed emanated from the AS, the AS will provide a hash parameter in the request to the client's callback URI. The client **_must_** verify this hash. |
There was a problem hiding this comment.
- Typo "redeirect"
- Change "identify provider" to identity provider
|
|
||
| </CodeBlock> | ||
|
|
||
| For more information refer to the <LinkOut href='https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol-20#name-calculating-the-interaction'> "Calculating the interaction hash"</LinkOut> section of the GNAP specification. |
There was a problem hiding this comment.
Can you remove the quotation marks around the link name?
hajjimo
requested review from
raducristianpopa
and removed request for
sabineschaller
|
|
||
| ## Hashing method | ||
|
|
||
| The hash base is generated by concatentating the following values in sequence using a single newline (0x0A) character to separate them: |
There was a problem hiding this comment.
| The hash base is generated by concatentating the following values in sequence using a single newline (0x0A) character to separate them: | |
| The hash base is generated by concatentating the following values in sequence using a single newline (\n) character to separate them: |
| The hash base is generated by concatentating the following values in sequence using a single newline (0x0A) character to separate them: | ||
|
|
||
| 1. `nonce` value sent by the client in the initial request. | ||
| 2. `nonce` value sent by the AS from the interaction finish response. |
There was a problem hiding this comment.
The interact nonce is returned after making the initial grant request (interaction instructions):
{
"interact": {
"redirect": "https://auth.rafiki.money/4CF492MLVMSW9MKMXKHQ",
"finish": "4105340a-05eb-4290-8739-f9e2b463bfa7" // <- nonce
},
"continue": {
"access_token": {
"value": "33OMUKMKSKU80UPRY5NM"
},
"uri": "https://auth.rafiki.money/continue/4CF492MLVMSW9MKMXKHQ",
"wait": 30
}
}| The ASCII encoding of this string is hashed with the algorithm specified in the `hash_method` parameter under the `finish` key of the interaction finish request. The byte array from the hash function is then encoded using URL-Safe Base64 with no padding. The resultant string is the hash value. | ||
|
|
||
| Unless specified by the client in the initial request, the `hash_method` will default to `sha-256`. If the client specifies the `hash_method`, the `hash_method` **_must_** be one of the hash name strings defined in the <LinkOut href='https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg'>IANA Named Information Hash Algorithm Registry</LinkOut>. |
There was a problem hiding this comment.
@mkurapov are we planning to support other hashing methods as well? If not I think we should only mention sha-256.
There was a problem hiding this comment.
I don't think so, we can just mention sha-256
|
|
||
| </CodeBlock> | ||
|
|
||
| The ASCII encoding of this string is hashed with the algorithm specified in the `hash_method` parameter under the `finish` key of the interaction finish request. The byte array from the hash function is then encoded using URL-Safe Base64 with no padding. The resultant string is the hash value. |
There was a problem hiding this comment.
In Rafiki we are doing only doing base64 encoding not base64url.
CC @mkurapov
- edit hash verification page for changes suggested by Radu - replace custom Disclosure components with details component - remove Disclosure references from Import statements
Changes proposed in this pull request
Context