You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This one requires careful consideration of the nonces and binding. I think the right outcome is for the NAC and TTC keys to be generated at the same time in the secure wallet environment such that the platform specific attestation to the NAC registrar can attest to both keys (and could use the TTC pub key hash as a nonce and the TTC-Join could use the NAC pub key as a nonce) such that when the NAC-Join happens the registrar can return a signed assertion binding the TTC public key to the verified-by-NAC-registrar hardware attestation which is presented to the TTC registrar on TTC-Join - along with either a NAC registrar generated identifier for the client. The TTC registrar must just check that the NAC used to call is valid and from the NAC registrar which signed the assertion.
This allows the TTC registrar to go back to the NAC registrar if any problems arise as unbounded issuance of NACs would not be readily apparent to the TTC registrar without some form of stable identifier. This then acts as an anchor for future nym/basename-based detection to ensure compromised wallets can be effectively excluded (and can't piggyback TTC issuance on valid NACs, etc).
And have the TTC get configured with NAC gpks and have NAC able to configure client TTC URIs/etc.
The text was updated successfully, but these errors were encountered: