BAP、BitcoinSchema、1sat ordinals、sigma protocol support for java

Bitcoin Attestation Protocol - BAP

A simple protocol to create a chain of trust for any kind of data on the Bitcoin blockchain
Authors: Siggi

Special thanks to Attila Aros & Satchmo

Inspired by the AUTHOR IDENTITY Protocol

NOTE: All examples in this document use fake identity keys, addresses and signatures. See the test data sets for real world examples that can be used in a test suite when developing a library.

• Intro
• Protocol
  • URN - Uniform Resource Names
  • Attributes are defined at schema.org
• Creating an identity (ID)
• Usage in an identity system (BAP-ID)
  • Attesting (ATTEST)
  • Verifying an identity attribute
  • Delegating signing to another identity
  • Publishing Identity information (ALIAS)
  • BAP uniKey
• Publishing data (DATA)
• Using as a Power of Attorney
• Blacklisting
  • Blacklisting transactions / addresses
  • Blacklisting IP addresses
  • Final note on blacklisting
• Giving consent to access of data
• Simple asserts
• Revoking an attestation
• BAP on the BSV Metanet - PROVISIONAL
• BAP w3c DID - PROVISIONAL
• Extending the protocol

TODO

• Finish DID specs - help needed
• Request feedback

Intro

The design goals:

1. A simple protocol for generic attestation of data, without the need to publish the data itself
2. Decouple the signing with an address from the funding source address (ie: does not require any on-chain transactions from the signing identity address)
3. Allow for rotation of signing keys without having to change the existing attestations
4. Allow for creation of an infinite amount of identities, but still allow for proving of attested attributes between the identities

Protocol

The protocol is defined using the Bitcom convention. The signing is done using the AUTHOR IDENTITY Protocol.

• The prefix of the protocol is 1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT;

1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT
[ID|ATTEST|ALIAS|DATA|REVOKE]
[ID Key|URN Attestation Hash]
[Sequence|Address|Data]
|
[AIP protocol address]
[AIP Signing Algorithm]
[AIP Signing Address]
[AIP Signature]

By default, all fields are signed, so the optional indices of the AIP can be left out.

The Sequence is added to the transaction to prevent replay of the transaction in case of a revocation. The transaction from the same signatory, with the highest Sequence is the current one.

The fourth field is used for the bitcoin signing address in an ID transaction only.

Example:

1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT
ATTEST
d4bcdd0f437d0d3bc588bb4e861d2e83e26e8bf9566ae541a5d43329213b1b13
0
|
15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva
BITCOIN_ECDSA
1Po6MLAPJsSAGyE8sXw3CgWcgxumNGjyqm
G8wW0NOCPFgGSoCtB2DZ+0CrLrh9ywAl0C5hnx78Q+7QNyPYzsFtkt4/TXkzkTwqbOT3Ofb1CYdNUv5a/jviPVA=

URN - Uniform Resource Names

The protocol makes use of URN's as a data carrier for the attestation data, as defined by the w3c.

URN's look like:

urn:[namespace identifier]:[...URN]

Examples for use in BAP:

Identity:

urn:bap:id:[Attribute name]:[Attribute value]:[Nonce]
  urn:bap:id:name:John Doe:e2c6fb4063cc04af58935737eaffc938011dff546d47b7fbb18ed346f8c4d4fa

Attestations:

urn:bap:attest:[Attribute hash]:[Identity key]
urn:bap:attest:42d2396ddfc3dec6acbd96830b844a10b8b2f065e60fbd5238b5267ab086bf4f:1CCWY6EXZwNqbrtW1SXGNFWdwipYT7Ur1Q

The URN is hashed using sha256 when used in a transaction sent to the blockchain.

Attributes are defined at schema.org

Attributes used in BAP should be defined at https://schema.org.

Especially the Person attributes, found at https://schema.org/Person, should be used in BAP.

Creating an identity (ID)

To create a new identity in BAP, we need to create 2 private keys and compute they public keys and the corresponding addresses. For easy management of the keys, it is recommended to use an HD Private key with known derivations.

rootAddress: 1WffojxvgpQBmUTigoss7VUdfN45JiiRK
firstAddress: 1K4c6YXR1ixNLAqrL8nx5HUQAPKbACTwDo

Signing identities in BAP are created by linking a unique identity key with bitcoin signing addresses. The identity key should be computed as a hash of the rootAddress. This links the 2 together and prevents others from creating an identity using the same identity key to create confusion.

The identity key follows the way a Bitcoin address is hashed to reduce the size of the key.

identityKey = base58( ripemd160 ( sha256 ( rootAddress ) ) )

Example identity key, note the hex values are fed as binary buffers to the hash functions and not as a string:

sha256(1WffojxvgpQBmUTigoss7VUdfN45JiiRK) = c38bc59316de9783b5f7a8ba19bc5d442f6c9b0988c48a241d1c58a1f4e9ae19
ripemd160(c38bc59316de9783b5f7a8ba19bc5d442f6c9b0988c48a241d1c58a1f4e9ae19) = afb3dcf52c2c661c35c8ec6a92cecbfc691ba371
base58(afb3dcf52c2c661c35c8ec6a92cecbfc691ba371) = 3SyWUZXvhidNcEHbAC3HkBnKoD2Q
identityKey: 3SyWUZXvhidNcEHbAC3HkBnKoD2Q

NOTE: This has been changed with the release of the BAP library. This allows a verifier to link the root address to the identity key. In the past the identity key was random. Older identites created at random will still work with the BAP library, but new identities should be created in this way.

To link this identity key to the root address and the signing address, an ID transaction is sent to the blockchain:

1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT
ID
3SyWUZXvhidNcEHbAC3HkBnKoD2Q
1K4c6YXR1ixNLAqrL8nx5HUQAPKbACTwDo
|
15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva
BITCOIN_ECDSA
1WffojxvgpQBmUTigoss7VUdfN45JiiRK
HB6Ye7ekxjKDkblJYL9lX3J2vhY75vl+WfVCq+wW3+y6S7XECkgYwUEVH3WEArRuDb/aVZ8ntLI/D0Yolb1dhD8=

The address 1WffojxvgpQBmUTigoss7VUdfN45JiiRK associated with the first instance of the identity key on-chain, is the identity control address (or rootAddress). This address should no be used anywhere, but can be used to destroy the identity, in case the latest linked key has been compromised.

When the signing address is rotated to a new key, a new ID transaction is created, this time signed by the previous address:

1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT
ID
3SyWUZXvhidNcEHbAC3HkBnKoD2Q
1JfMQDtBKYi6z65M9uF2gxgLv7E8pPR6MA
|
15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva
BITCOIN_ECDSA
1K4c6YXR1ixNLAqrL8nx5HUQAPKbACTwDo
HB6Ye7ekxjKDkblJYL9lX3J2vhY75vl+WfVCq+wW3+y6S7XECkgYwUEVH3WEArRuDb/aVZ8ntLI/D0Yolb1dhD8=

In this way, we have created a way to rotate the signing keys for a certain identity as often as we want, with each signing key being immutably saved on the blockchain.

Any signatures done for the identity key should be done using the active key at that time.

To destroy the identity, an ID transaction is sent to 0, signed with the address from the first ever transaction 1WffojxvgpQBmUTigoss7VUdfN45JiiRK;

1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT
ID
3SyWUZXvhidNcEHbAC3HkBnKoD2Q
0
|
15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva
BITCOIN_ECDSA
1WffojxvgpQBmUTigoss7VUdfN45JiiRK
HB6Ye7ekxjKDkblJYL9lX3J2vhY75vl+WfVCq+wW3+y6S7XECkgYwUEVH3WEArRuDb/aVZ8ntLI/D0Yolb1dhD8=

Usage in an identity system (BAP-ID)

A BAP identity is defined as an identity key that has attested identity attributes, verified by one or more authorities. These authorities are outside the scope of this description, but are not governed or controlled.

All identity attributes have the following characteristics:

urn:bap:id:[Attribute name]:[Attribute value]:[Nonce]

Attribute	Description
Attribute name	The name of the attribute being described
Attribute value	The value of the attribute being described with the name
Nonce	A unique random string to make sure the entropy of hashing the urn will not cause collision and not allow for dictionary attacks

A user may want to create multiple identities with a varying degree of details available about that identity. Let's take a couple of examples:

Identity 1 (3SyWUZXvhidNcEHbAC3HkBnKoD2Q):

urn:bap:id:name:John Doe:e2c6fb4063cc04af58935737eaffc938011dff546d47b7fbb18ed346f8c4d4fa
urn:bap:id:birthday:1990-05-22:e61f23cbbb2284842d77965e2b0e32f0ca890b1894ca4ce652831347ee3596d9
urn:bap:id:over18:1:480ca17ccaacd671b28dc811332525f2f2cd594d8e8e7825de515ce5d52d30e8
urn:bap:id:address:51391 Moorpark Ave #104, San Jose, CA 95129, United States:44d47d2375c8346c7ceeab1904360aaf572b1c940c1bd66ffd5cf88fdf06bc05
urn:bap:id:passportNr:US2343242:9c06a0fb0e2d9cef4928855076255e4df3375e2807cf37bc028ddb282f811ac8
urn:bap:id:passportExpiration:2022-02-23:d61a39afb463b42c3e419463a028deb3e9e2cebf67953864e9f9e7869677e7cb

Identity 2 (b71a658ec49a9cb099fd5d3cf0aafce28f1d464fa6e496f61c8048d8ed56edc1):

urn:bap:id:name:John Doe:6637be9df2e114ce19a287ff48841899ef4a5762a5f9dc47aef62fe4f579bf93
urn:bap:id:email:john.doen@example.com:2864fd138ab1e9ddaaea763c77a45898dac64a26229f9f3d0f2280e4bfa915de
urn:bap:id:over18:1:5f48f9be1644834933cec74a299d109d18f01e77c9552545d2eae4d0c929000b

Identity 3 (10ef2b1bb05185d0dbae41e1bfefe0c2deb2d389f38fe56daa2cc28a9ba82fc7):

urn:bap:id:alternateName:Johnny:7a8d693bce6b6c1cf1dd81468a52b69829e465ff9b0762cf77965309df3ad4c8

NOTE: The random nonce should not be re-used across identities. Always create a new random secret for each attribute.

Attesting (ATTEST)

Anyone can attest for any identity by broadcasting a bitcoin transaction with a signature from their private key of the attributes of the identity.

All attestations have the following characteristics:

urn:bap:attest:[Attribute hash]:[Identity key]

Attribute	Description
Attribute hash	A hash of the urn attribute being attested
Identity key	The unique identity key of the owner of the attestation

Take for example a bank, Banco De Bitcoin, with a known and trusted identity key of ezY2h8B5sj7SHGw8i1KhHtRvgM5 which is linked via an ID transaction to 1K4c6YXR1ixNLAqrL8nx5HUQAPKbACTwDo. To attest that the bank has seen the information in the identity attribute and that it is correct, the bank would sign an attestation with the identity information together with the given identity key.

1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT
ATTEST
[Attestation hash]
[Sequence]
|
15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva
[Signature algorithm]
[Address of signer]
[Signature]

For the name urn for the Identity 1 (3SyWUZXvhidNcEHbAC3HkBnKoD2Q) in above example:

• We take the hash of urn:bap:id:name:John Doe:e2c6fb4063cc04af58935737eaffc938011dff546d47b7fbb18ed346f8c4d4fa = b17c8e606afcf0d8dca65bdf8f33d275239438116557980203c82b0fae259838
• Then create an attestation urn for the address: urn:bap:id:attest:b17c8e606afcf0d8dca65bdf8f33d275239438116557980203c82b0fae259838:3SyWUZXvhidNcEHbAC3HkBnKoD2Q
• Then hash the attestation for our transaction: 89cd658c0ce3ff62db4270a317c35f8a7dfe1242e2cc94232aa3947d77f82431
• Then the attestation is signed with the private key belonging to the trusted authority (with address 1K4c6YXR1ixNLAqrL8nx5HUQAPKbACTwDo);

1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT
ATTEST
89cd658c0ce3ff62db4270a317c35f8a7dfe1242e2cc94232aa3947d77f82431
0
|
15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva
BITCOIN_ECDSA
1K4c6YXR1ixNLAqrL8nx5HUQAPKbACTwDo
HB6Ye7ekxjKDkblJYL9lX3J2vhY75vl+WfVCq+wW3+y6S7XECkgYwUEVH3WEArRuDb/aVZ8ntLI/D0Yolb1dhD8=

Since the hash of our attestation is always the same, any authority attesting the identity attribute will broadcast a transaction where the 3rd item is the same. In this way it is possible to search (using for instance Planaria) through the blockchain for all attestations of the identity attribute and select the one most trusted.

Verifying an identity attribute

For a user to prove their identity, that has been verified by a trusted authority, the user does the following.

He shares his identity key 3SyWUZXvhidNcEHbAC3HkBnKoD2Q, the full urn urn:bap:id:name:John Doe:e2c6fb4063cc04af58935737eaffc938011dff546d47b7fbb18ed346f8c4d4fa and signs a challenge message from the party that request an identity verification.

The receiving party can now verify:

• That the user is the owner of the address 1JfMQDtBKYi6z65M9uF2gxgLv7E8pPR6MA by verifying the signature
• That the identity 3SyWUZXvhidNcEHbAC3HkBnKoD2Q is linked to the address via an ID record
• That the attestation urn has been signed by that latest valid address of Banco De Bitcoin.
• Thereby verifying that the user signing the message has been attested by the bank to have the name John Doe.

NOTE: No unneeded sensitive information has been shared and it is not possible to infer any other information from the information sent. The only thing the receiver now knows is that the person doing the signing is called John Doe.

Delegating signing to another identity

With BAP, it is very easy to create an infinite number of identities for a user. This is even encouraged to preserve privacy.

When for instance a KYC check is done, this check is done for a certain identity. Replicating this KYC check for all identities for a user, to be able to use in all access applications, is impractical. To solve this we must be able to link, or delegate, from one identity to another.

urn:bap:delegate:<from idKey>:<to IdKey>:<Nonce>

Example:

var attestation = 'urn:bap:delegate:3SyWUZXvhidNcEHbAC3HkBnKoD2Q:341d782c56a588ccdd3ebb181d1dbb4699bdb5fb9956b7bd07e917d955acdb04:7f2fe5aac07e2d4c43bdb232029ed157acf0272eac94a2f75cc17566c01a5e89';
var attestationHash = sha256(attestation); // 2dbb381888f973a0db3bf311e551a6ac2f3ab792420262d8a6f65ef4feb8c1ef

This links, or delegates, from identity 3SyWUZXvhidNcEHbAC3HkBnKoD2Q to identity 341d782c56a588ccdd3ebb181d1dbb4699bdb5fb9956b7bd07e917d955acdb04;

The attestation can be published to the blockchain, signed by the identity 3SyWUZXvhidNcEHbAC3HkBnKoD2Q;

1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT
ATTEST
2dbb381888f973a0db3bf311e551a6ac2f3ab792420262d8a6f65ef4feb8c1ef
0
|
15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva
BITCOIN_ECDSA
1JfMQDtBKYi6z65M9uF2gxgLv7E8pPR6MA
HB6Ye7ekxjKDkblJYL9lX3J2vhY75vl+WfVCq+wW3+y6S7XECkgYwUEVH3WEArRuDb/aVZ8ntLI/D0Yolb1dhD8=

Showing that it is possible to use the verified attributes from 3SyWUZXvhidNcEHbAC3HkBnKoD2Q in identity 341d782c56a588ccdd3ebb181d1dbb4699bdb5fb9956b7bd07e917d955acdb04 can now be done by sharing the delegation. The delegation attestation will be available to check on-chain.

The challenge sent by the application requesting the attributes should be signed by both (!) identites, to proof access to the private keys of both identities.

NOTE: The grant published on-chain for the attributes shared must be signed by the delegating identity 3SyWUZXvhidNcEHbAC3HkBnKoD2Q, and not 341d782c56a588ccdd3ebb181d1dbb4699bdb5fb9956b7bd07e917d955acdb04;

NOTE: The receiving end should store both identity keys to be able to proof they have received access to the data of the user. The could be stored as a concatenation of the two identity strings: 341d782c56a588ccdd3ebb181d1dbb4699bdb5fb9956b7bd07e917d955acdb04<-3SyWUZXvhidNcEHbAC3HkBnKoD2Q;

NOTE: The main identity, for which a KYC has been done, should never directly be used in any application. A new identity should be created for each and every application accessed.

Publishing Identity information (ALIAS)

It is possible to publish information about an identity by using the BAP ALIAS keyword. This tells the world that an identity key should be seen as belonging to the entity published in the alias.

It is recommended to only use the ALIAS keyword for companies that need (or want) to link an identity key to th

Bitcoin Attestation Protocol - BAP

A simple protocol to create a chain of trust for any kind of data on the Bitcoin blockchain
Authors: Siggi

Special thanks to Attila Aros & Satchmo

Inspired by the AUTHOR IDENTITY Protocol

NOTE: All examples in this document use fake identity keys, addresses and signatures. See the test data sets for real world examples that can be used in a test suite when developing a library.

• Intro
• Protocol
  • URN - Uniform Resource Names
  • Attributes are defined at schema.org
• Creating an identity (ID)
• Usage in an identity system (BAP-ID)
  • Attesting (ATTEST)
  • Verifying an identity attribute
  • Delegating signing to another identity
  • Publishing Identity information (ALIAS)
  • BAP uniKey
• Publishing data (DATA)
• Using as a Power of Attorney
• Blacklisting
  • Blacklisting transactions / addresses
  • Blacklisting IP addresses
  • Final note on blacklisting
• Giving consent to access of data
• Simple asserts
• Revoking an attestation
• BAP on the BSV Metanet - PROVISIONAL
• BAP w3c DID - PROVISIONAL
• Extending the protocol

TODO

• Finish DID specs - help needed
• Request feedback

Intro

The design goals:

1. A simple protocol for generic attestation of data, without the need to publish the data itself
2. Decouple the signing with an address from the funding source address (ie: does not require any on-chain transactions from the signing identity address)
3. Allow for rotation of signing keys without having to change the existing attestations
4. Allow for creation of an infinite amount of identities, but still allow for proving of attested attributes between the identities

Protocol

The protocol is defined using the Bitcom convention. The signing is done using the AUTHOR IDENTITY Protocol.

• The prefix of the protocol is 1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT;

1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT
[ID|ATTEST|ALIAS|DATA|REVOKE]
[ID Key|URN Attestation Hash]
[Sequence|Address|Data]
|
[AIP protocol address]
[AIP Signing Algorithm]
[AIP Signing Address]
[AIP Signature]

By default, all fields are signed, so the optional indices of the AIP can be left out.

The Sequence is added to the transaction to prevent replay of the transaction in case of a revocation. The transaction from the same signatory, with the highest Sequence is the current one.

The fourth field is used for the bitcoin signing address in an ID transaction only.

Example:

1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT
ATTEST
d4bcdd0f437d0d3bc588bb4e861d2e83e26e8bf9566ae541a5d43329213b1b13
0
|
15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva
BITCOIN_ECDSA
1Po6MLAPJsSAGyE8sXw3CgWcgxumNGjyqm
G8wW0NOCPFgGSoCtB2DZ+0CrLrh9ywAl0C5hnx78Q+7QNyPYzsFtkt4/TXkzkTwqbOT3Ofb1CYdNUv5a/jviPVA=

URN - Uniform Resource Names

The protocol makes use of URN's as a data carrier for the attestation data, as defined by the w3c.

URN's look like:

urn:[namespace identifier]:[...URN]

Examples for use in BAP:

Identity:

urn:bap:id:[Attribute name]:[Attribute value]:[Nonce]
  urn:bap:id:name:John Doe:e2c6fb4063cc04af58935737eaffc938011dff546d47b7fbb18ed346f8c4d4fa

Attestations:

urn:bap:attest:[Attribute hash]:[Identity key]
urn:bap:attest:42d2396ddfc3dec6acbd96830b844a10b8b2f065e60fbd5238b5267ab086bf4f:1CCWY6EXZwNqbrtW1SXGNFWdwipYT7Ur1Q

The URN is hashed using sha256 when used in a transaction sent to the blockchain.

Attributes are defined at schema.org

Attributes used in BAP should be defined at https://schema.org.

Especially the Person attributes, found at https://schema.org/Person, should be used in BAP.

Creating an identity (ID)

To create a new identity in BAP, we need to create 2 private keys and compute they public keys and the corresponding addresses. For easy management of the keys, it is recommended to use an HD Private key with known derivations.

rootAddress: 1WffojxvgpQBmUTigoss7VUdfN45JiiRK
firstAddress: 1K4c6YXR1ixNLAqrL8nx5HUQAPKbACTwDo

Signing identities in BAP are created by linking a unique identity key with bitcoin signing addresses. The identity key should be computed as a hash of the rootAddress. This links the 2 together and prevents others from creating an identity using the same identity key to create confusion.

The identity key follows the way a Bitcoin address is hashed to reduce the size of the key.

identityKey = base58( ripemd160 ( sha256 ( rootAddress ) ) )

Example identity key, note the hex values are fed as binary buffers to the hash functions and not as a string:

sha256(1WffojxvgpQBmUTigoss7VUdfN45JiiRK) = c38bc59316de9783b5f7a8ba19bc5d442f6c9b0988c48a241d1c58a1f4e9ae19
ripemd160(c38bc59316de9783b5f7a8ba19bc5d442f6c9b0988c48a241d1c58a1f4e9ae19) = afb3dcf52c2c661c35c8ec6a92cecbfc691ba371
base58(afb3dcf52c2c661c35c8ec6a92cecbfc691ba371) = 3SyWUZXvhidNcEHbAC3HkBnKoD2Q
identityKey: 3SyWUZXvhidNcEHbAC3HkBnKoD2Q

NOTE: This has been changed with the release of the BAP library. This allows a verifier to link the root address to the identity key. In the past the identity key was random. Older identites created at random will still work with the BAP library, but new identities should be created in this way.

To link this identity key to the root address and the signing address, an ID transaction is sent to the blockchain:

1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT
ID
3SyWUZXvhidNcEHbAC3HkBnKoD2Q
1K4c6YXR1ixNLAqrL8nx5HUQAPKbACTwDo
|
15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva
BITCOIN_ECDSA
1WffojxvgpQBmUTigoss7VUdfN45JiiRK
HB6Ye7ekxjKDkblJYL9lX3J2vhY75vl+WfVCq+wW3+y6S7XECkgYwUEVH3WEArRuDb/aVZ8ntLI/D0Yolb1dhD8=

The address 1WffojxvgpQBmUTigoss7VUdfN45JiiRK associated with the first instance of the identity key on-chain, is the identity control address (or rootAddress). This address should no be used anywhere, but can be used to destroy the identity, in case the latest linked key has been compromised.

When the signing address is rotated to a new key, a new ID transaction is created, this time signed by the previous address:

1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT
ID
3SyWUZXvhidNcEHbAC3HkBnKoD2Q
1JfMQDtBKYi6z65M9uF2gxgLv7E8pPR6MA
|
15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva
BITCOIN_ECDSA
1K4c6YXR1ixNLAqrL8nx5HUQAPKbACTwDo
HB6Ye7ekxjKDkblJYL9lX3J2vhY75vl+WfVCq+wW3+y6S7XECkgYwUEVH3WEArRuDb/aVZ8ntLI/D0Yolb1dhD8=

In this way, we have created a way to rotate the signing keys for a certain identity as often as we want, with each signing key being immutably saved on the blockchain.

Any signatures done for the identity key should be done using the active key at that time.

To destroy the identity, an ID transaction is sent to 0, signed with the address from the first ever transaction 1WffojxvgpQBmUTigoss7VUdfN45JiiRK;

1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT
ID
3SyWUZXvhidNcEHbAC3HkBnKoD2Q
0
|
15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva
BITCOIN_ECDSA
1WffojxvgpQBmUTigoss7VUdfN45JiiRK
HB6Ye7ekxjKDkblJYL9lX3J2vhY75vl+WfVCq+wW3+y6S7XECkgYwUEVH3WEArRuDb/aVZ8ntLI/D0Yolb1dhD8=

Usage in an identity system (BAP-ID)

A BAP identity is defined as an identity key that has attested identity attributes, verified by one or more authorities. These authorities are outside the scope of this description, but are not governed or controlled.

All identity attributes have the following characteristics:

urn:bap:id:[Attribute name]:[Attribute value]:[Nonce]

Attribute	Description
Attribute name	The name of the attribute being described
Attribute value	The value of the attribute being described with the name
Nonce	A unique random string to make sure the entropy of hashing the urn will not cause collision and not allow for dictionary attacks

A user may want to create multiple identities with a varying degree of details available about that identity. Let's take a couple of examples:

Identity 1 (3SyWUZXvhidNcEHbAC3HkBnKoD2Q):

urn:bap:id:name:John Doe:e2c6fb4063cc04af58935737eaffc938011dff546d47b7fbb18ed346f8c4d4fa
urn:bap:id:birthday:1990-05-22:e61f23cbbb2284842d77965e2b0e32f0ca890b1894ca4ce652831347ee3596d9
urn:bap:id:over18:1:480ca17ccaacd671b28dc811332525f2f2cd594d8e8e7825de515ce5d52d30e8
urn:bap:id:address:51391 Moorpark Ave #104, San Jose, CA 95129, United States:44d47d2375c8346c7ceeab1904360aaf572b1c940c1bd66ffd5cf88fdf06bc05
urn:bap:id:passportNr:US2343242:9c06a0fb0e2d9cef4928855076255e4df3375e2807cf37bc028ddb282f811ac8
urn:bap:id:passportExpiration:2022-02-23:d61a39afb463b42c3e419463a028deb3e9e2cebf67953864e9f9e7869677e7cb

Identity 2 (b71a658ec49a9cb099fd5d3cf0aafce28f1d464fa6e496f61c8048d8ed56edc1):

urn:bap:id:name:John Doe:6637be9df2e114ce19a287ff48841899ef4a5762a5f9dc47aef62fe4f579bf93
urn:bap:id:email:john.doen@example.com:2864fd138ab1e9ddaaea763c77a45898dac64a26229f9f3d0f2280e4bfa915de
urn:bap:id:over18:1:5f48f9be1644834933cec74a299d109d18f01e77c9552545d2eae4d0c929000b

Identity 3 (10ef2b1bb05185d0dbae41e1bfefe0c2deb2d389f38fe56daa2cc28a9ba82fc7):

urn:bap:id:alternateName:Johnny:7a8d693bce6b6c1cf1dd81468a52b69829e465ff9b0762cf77965309df3ad4c8

NOTE: The random nonce should not be re-used across identities. Always create a new random secret for each attribute.

Attesting (ATTEST)

Anyone can attest for any identity by broadcasting a bitcoin transaction with a signature from their private key of the attributes of the identity.

All attestations have the following characteristics:

urn:bap:attest:[Attribute hash]:[Identity key]

Attribute	Description
Attribute hash	A hash of the urn attribute being attested
Identity key	The unique identity key of the owner of the attestation

Take for example a bank, Banco De Bitcoin, with a known and trusted identity key of ezY2h8B5sj7SHGw8i1KhHtRvgM5 which is linked via an ID transaction to 1K4c6YXR1ixNLAqrL8nx5HUQAPKbACTwDo. To attest that the bank has seen the information in the identity attribute and that it is correct, the bank would sign an attestation with the identity information together with the given identity key.

1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT
ATTEST
[Attestation hash]
[Sequence]
|
15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva
[Signature algorithm]
[Address of signer]
[Signature]

For the name urn for the Identity 1 (3SyWUZXvhidNcEHbAC3HkBnKoD2Q) in above example:

• We take the hash of urn:bap:id:name:John Doe:e2c6fb4063cc04af58935737eaffc938011dff546d47b7fbb18ed346f8c4d4fa = b17c8e606afcf0d8dca65bdf8f33d275239438116557980203c82b0fae259838
• Then create an attestation urn for the address: urn:bap:id:attest:b17c8e606afcf0d8dca65bdf8f33d275239438116557980203c82b0fae259838:3SyWUZXvhidNcEHbAC3HkBnKoD2Q
• Then hash the attestation for our transaction: 89cd658c0ce3ff62db4270a317c35f8a7dfe1242e2cc94232aa3947d77f82431
• Then the attestation is signed with the private key belonging to the trusted authority (with address 1K4c6YXR1ixNLAqrL8nx5HUQAPKbACTwDo);

1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT
ATTEST
89cd658c0ce3ff62db4270a317c35f8a7dfe1242e2cc94232aa3947d77f82431
0
|
15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva
BITCOIN_ECDSA
1K4c6YXR1ixNLAqrL8nx5HUQAPKbACTwDo
HB6Ye7ekxjKDkblJYL9lX3J2vhY75vl+WfVCq+wW3+y6S7XECkgYwUEVH3WEArRuDb/aVZ8ntLI/D0Yolb1dhD8=

Since the hash of our attestation is always the same, any authority attesting the identity attribute will broadcast a transaction where the 3rd item is the same. In this way it is possible to search (using for instance Planaria) through the blockchain for all attestations of the identity attribute and select the one most trusted.

Verifying an identity attribute

For a user to prove their identity, that has been verified by a trusted authority, the user does the following.

He shares his identity key 3SyWUZXvhidNcEHbAC3HkBnKoD2Q, the full urn urn:bap:id:name:John Doe:e2c6fb4063cc04af58935737eaffc938011dff546d47b7fbb18ed346f8c4d4fa and signs a challenge message from the party that request an identity verification.

The receiving party can now verify:

• That the user is the owner of the address 1JfMQDtBKYi6z65M9uF2gxgLv7E8pPR6MA by verifying the signature
• That the identity 3SyWUZXvhidNcEHbAC3HkBnKoD2Q is linked to the address via an ID record
• That the attestation urn has been signed by that latest valid address of Banco De Bitcoin.
• Thereby verifying that the user signing the message has been attested by the bank to have the name John Doe.

NOTE: No unneeded sensitive information has been shared and it is not possible to infer any other information from the information sent. The only thing the receiver now knows is that the person doing the signing is called John Doe.

Delegating signing to another identity

With BAP, it is very easy to create an infinite number of identities for a user. This is even encouraged to preserve privacy.

When for instance a KYC check is done, this check is done for a certain identity. Replicating this KYC check for all identities for a user, to be able to use in all access applications, is impractical. To solve this we must be able to link, or delegate, from one identity to another.

urn:bap:delegate:<from idKey>:<to IdKey>:<Nonce>

Example:

var attestation = 'urn:bap:delegate:3SyWUZXvhidNcEHbAC3HkBnKoD2Q:341d782c56a588ccdd3ebb181d1dbb4699bdb5fb9956b7bd07e917d955acdb04:7f2fe5aac07e2d4c43bdb232029ed157acf0272eac94a2f75cc17566c01a5e89';
var attestationHash = sha256(attestation); // 2dbb381888f973a0db3bf311e551a6ac2f3ab792420262d8a6f65ef4feb8c1ef

This links, or delegates, from identity 3SyWUZXvhidNcEHbAC3HkBnKoD2Q to identity 341d782c56a588ccdd3ebb181d1dbb4699bdb5fb9956b7bd07e917d955acdb04;

The attestation can be published to the blockchain, signed by the identity 3SyWUZXvhidNcEHbAC3HkBnKoD2Q;

1BAPSuaPnfGnSBM3GLV9yhxUdYe4vGbdMT
ATTEST
2dbb381888f973a0db3bf311e551a6ac2f3ab792420262d8a6f65ef4feb8c1ef
0
|
15PciHG22SNLQJXMoSUaWVi7WSqc7hCfva
BITCOIN_ECDSA
1JfMQDtBKYi6z65M9uF2gxgLv7E8pPR6MA
HB6Ye7ekxjKDkblJYL9lX3J2vhY75vl+WfVCq+wW3+y6S7XECkgYwUEVH3WEArRuDb/aVZ8ntLI/D0Yolb1dhD8=

Showing that it is possible to use the verified attributes from 3SyWUZXvhidNcEHbAC3HkBnKoD2Q in identity 341d782c56a588ccdd3ebb181d1dbb4699bdb5fb9956b7bd07e917d955acdb04 can now be done by sharing the delegation. The delegation attestation will be available to check on-chain.

The challenge sent by the application requesting the attributes should be signed by both (!) identites, to proof access to the private keys of both identities.

NOTE: The grant published on-chain for the attributes shared must be signed by the delegating identity 3SyWUZXvhidNcEHbAC3HkBnKoD2Q, and not 341d782c56a588ccdd3ebb181d1dbb4699bdb5fb9956b7bd07e917d955acdb04;

NOTE: The receiving end should store both identity keys to be able to proof they have received access to the data of the user. The could be stored as a concatenation of the two identity strings: 341d782c56a588ccdd3ebb181d1dbb4699bdb5fb9956b7bd07e917d955acdb04<-3SyWUZXvhidNcEHbAC3HkBnKoD2Q;

NOTE: The main identity, for which a KYC has been done, should never directly be used in any application. A new identity should be created for each and every application accessed.

Publishing Identity information (ALIAS)

It is possible to publish information about an identity by using the BAP ALIAS keyword. This tells the world that an identity key should be seen as belonging to the entity published in the alias.

It is recommended to only use the ALIAS keyword for companies that need (or want) to link an identity key to th