Draft: draft-ietf-privacypass-architecture

Commentary: This is a little hard to process ... An inbound PR I have proposes a change to the first diagram that might help here . A little work on this is probably necessary . ! 
 A few things : When drawing arrows on lines , the line will connect with the line neatly if there is a connector or if there is an arrow adjacent to the line : This puts the arrow on the line , which renders a gap in the line . Avoid this : The bottom - left corner here is not curved , because the detection of corners needs three characters : the corner and a line either side of that , so ... Not : 
 can you say more about how it 's hard to process ? As we recently discussed , we 're burdened by being too close to this work , so it 's hard for me to see a substantial difference between the diagram in this issue and that which you proposed in the recently merged PR . Is it not clear who touches or sees each message ? Part of the challenge in this particular diagram -- and any in which the attester is party to the protocol -- is that the attester may be inline or may not be ! The architecture does not require the attester to be inline , it really only requires that the token request from a client be somehow blessed by the attester . I 'll think about ways to better visualize this , but clarification about the source of confusion would be super helpful . 
 For me , the hardest part of these diagrams is that the start and end of the end of the arrows are n't really attached to anything in particular . You rely on horizontal alignment a fair bit ( the arrow starts approximately under the label " Issuer " , so it 's probably a message from the issuer ) . In comparison , the diagram I provided had lines and boxes connecting them . This is probably a more illustrative example : ! Are the TokenRequest and TokenResponse labels on the lines ? Where do these arrows start ? Is the Client / Attester / Issuer box a single entity ( obviously , no ) given how the challenge arrows hit it . Which entities perform attestation ? Then there are the formatting issues , some of which I will concede are specific to aasvg , see the above comment . 
 Thanks -- that 's helpful . I think should resolve the confusion .
The Privacy Pass issuance protocol, described in ISSUANCE, is a two-
message protocol that takes as input a TokenChallenge from the
redemption protocol (AUTHSCHEME, Section 2.1) and produces a Token
(AUTHSCHEME, Section 2.2), as shown in the figure below.
The Privacy Pass issuance protocol, described in ISSUANCE, is a two-
message protocol that takes as input a TokenChallenge from the
redemption protocol (AUTHSCHEME, Section 2.1) and produces a Token
(AUTHSCHEME, Section 2.2), as shown in fig-overview.
In this model, the Origin, Attester, and Issuer are all operated by
the same entity, as shown in the figure below.
In this model, the Origin, Attester, and Issuer are all operated by
the same entity, as shown in fig-deploy-shared.
In this model, the Attester and Issuer are operated by the same
entity that is separate from the Origin.  The Origin trusts the joint
Attester and Issuer to perform attestation and issue Tokens.  Clients
interact with the joint Attester and Issuer for attestation and
issuance.  This arrangement is shown in the figure below.
In this model, the Attester and Issuer are operated by the same
entity that is separate from the Origin.  The Origin trusts the joint
Attester and Issuer to perform attestation and issue Tokens.  Clients
interact with the joint Attester and Issuer for attestation and
issuance.  This arrangement is shown in fig-deploy-joint-issuer.
In this model, the Origin and Issuer are operated by the same entity,
separate from the Attester, as shown in the figure below.  The Issuer
accepts token requests that come from trusted Attesters.  Since the
Attester and Issuer are separate entities, the Attester must
authenticate itself to the Issuer.  In settings where the Attester is
a Client-trusted service, one way Attesters can authenticate to
Issuers is via mutually-authenticated TLS.  However, alernative
authentication mechanisms are possible.  This arrangement is shown
below.
In this model, the Origin and Issuer are operated by the same entity,
separate from the Attester, as shown in the figure below.  The Issuer
accepts token requests that come from trusted Attesters.  Since the
Attester and Issuer are separate entities, the Attester must
authenticate itself to the Issuer.  In settings where the Attester is
a Client-trusted service, one way Attesters can authenticate to
Issuers is via mutually-authenticated TLS.  However, alernative
authentication mechanisms are possible.  This arrangement is shown in
fig-deploy-joint-origin.
In this model, the Origin, Attester, and Issuer are all operated by
different entities, as shown in the figure below.  As with the joint
Origin and Issuer model, the Issuer accepts token requests that come
from trusted Attesters, and the details of that trust establishment
depend on the issuance protocol and relationship between Attester and
Issuer.
In this model, the Origin, Attester, and Issuer are all operated by
different entities, as shown in the figure below.  As with the joint
Origin and Issuer model, the Issuer accepts token requests that come
from trusted Attesters, and the details of that trust establishment
depend on the issuance protocol and relationship between Attester and
Issuer.  This arrangement is shown in fig-overview.