Concerns about usernames in Auth Responses

Core Blockchain
#1

Consider the issuer claim from the example auth response:

{ 
  header: { 
    typ: 'JWT', 
    alg: 'ES256' 
  },
  payload: { 
    issuer: { 
      publicKey: '03fdd57adec3d438ea237fe46b33ee1e016eda6b585c3e27ea66686c2ea5358479',
      username: 'ryan.id',
      publicKeychain: 'xpub661MyMwAqRbcFQVrQr4Q4kPjaP4JjWaf39fBVKjPdK6oGBayE46GAmKzo5UDPQdLSM9DufZiP8eauy56XNuHicBySvZp7J5wsyQVpi2axzZ',
      chainPath: 'bd62885ec3f0e3838043115f4ce25eedd22cc86711803fb0c19601eeef185e39'
    },
    issuedAt: 1444259422196,
    challenge: '0b42722b-e781-434a-805d-c09c476e86b9' 
  },
  signature: '8TLQF_PI_egjP6WVlmf2rxPH-PMgrSDHGKE7d29qxU5KBRMlHppOIx69AoBdEEFr0HSFW0mDbM60W3kHC5jc-Q' 
}

I am concerned that including an username sub-claim creates an avenue for abuse if an application ever decides to lazily accept said sub-claim in the token.

In this context we cannot trust the token regarding the relationship between publicKey and username. The token is signed, proving possession of private key matching the indicated HD public key, however, this does not adequately prove agency over 'ryan.id'. For that we would have to query our blockstack node and verify the pairwise relationship (right?).

If we must hit our blockstack node to verify that relationship, is there value in including both in the token instead of discovering username using the node we trust?

#2

That is correct. You have to verify the following relationships: NAME --> ADDRESS OWNING THE NAME --> CHAIN PATH --> PARENT ADDRESS. There’s code in the auth library for verifying all of this. That said, I think it should be simplified.[quote=“wanderingbort, post:1, topic:458”]

If we must hit our blockstack node to verify that relationship, is there value in including both in the token instead of discovering username using the node we trust?
[/quote]

How do you suggest we do this?

#3

I think I jumped the gun a bit by thinking there was enough key data do back in to the owning name. Now that I’ve looked into the api code I see that this is not really addressable without the name claim. Perhaps when/if the ‘bsk’ identifiers are accepted that will supplant the name claim.

I’m going to have to dig in to the HDWallet code to check, does any of that keying information meet the criteria that it is either invalid or it is redundant in light of the information we’d get back from determining the address that owns the name? I erroneously thought the username claim fit this but I admit it doesn’t.