Signature Verification
BPP/BAP verifies BG signature
The BPP/BAP performs the following steps to authenticate the BAP/BPP and the BG and also ensure message integrity.
- Get keyId from the Proxy-Authorization header
- Split the keyID string using the delimiter
|
. - The keyID uses the format {subscriber id}|{unique_public_key_id}|{signing algorithm} . If the signing algorithm extracted from the keyId does not match the value of the algorithm field in the Proxy-Authorization header, then the BPP should return an error.
- The keyID also contains a unique_public_key_id which is used when the BG has uploaded multiple public keys to a registry OR when the same domain is being used for implementing multiple subscribers
- The BG will now look up the registry for the public key of the subscriber by sending the subscriber_id and the unique_key_id via the lookup API or by retrieving a cached copy of the subscriber’s public key matching the subscriber_id and unique_key_id. If no valid key is found, the BPP must return
- BPP will use the BG’s public key to verify the signature. If signature is verified, the BG is considered to be authenticated.
- If the signature is not verified, the BPP must return a NACK response with 401 Unauthorised response code with a Proxy-Authenticate header. For example, for an invalid BG signature, the BPP must return the following:
BG verifies BAP/BPP signature
The BG performs the following steps to authenticate the BAP/BPP and also ensure message integrity.
- BG gets keyId from the Authorization header
- BG splits the keyId string into subscriber ID, Unique Key ID and algorithm using the delimiter “|”.
- The keyId uses the format {subscriber id}|{unique_key_id}|{signing algorithm} . If the signing algorithm extracted from the keyId does not match the value of the algorithm parameter in the Authorization header, then the BG should return an 401 unauthorised error.
- The keyId also contains a unique_key_id which is used when the BAP has uploaded multiple public keys to a registry OR when the same domain is being used for implementing multiple types of subscribers
- The BG will now look up the registry for the public key of the subscriber by sending the subscriber_id and the unique_key_id via the lookup API or by retrieving a cached copy of the subscriber’s public key matching the subscriber_id and unique_key_id
- BG will use the BAP’s public key to verify the signature. If signature is verified, the BAP is considered to be authenticated. If not BG should return a 401 error
- If the signature is not verified, the BG must return a NACK response with 401 Unauthorised response code with a WWW-Authenticate header. For example, for an invalid signature, the BG must return the following:
Headers:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Signature realm="example-bg.com",headers="(created) (expires) digest"
...
Request Body:
{
"message": {
"ack": {
"status": "NACK"
}
}
}