TBPROTO-09: address implementation/api guidance

[equalsJeffH]

Mike and I have crafted proposed text to resolve #53 "add TB api guidance". it comprises a new "Implementation considerations" section and an additional paragraph in the Privacy Considerations section.

[equalsJeffH]

Thanks for making these mods, Mike!

regarding the above section..

hmm, this spec is overall written in terms of "client", rather than "(web) user agent". E.g., the latter term is first introduced in the section preceding this one and occurs only a few times. So I think we can simplify the first paragraph accordingly. Plus, the second paragraph essentially repeats info that's in the first.

how about the below build on the above?

<t>
  HTTPS-based applications may have multi-party use 
  cases other than, or in addition to, the HTTP redirect-based 
  signaling-and-conveyance of referred token bindings, as 
  presented above in <xref target="sctn-http-redir">.
</t>
<t>
  Thus, generic Token Binding implementations intended to support 
  any HTTPS-based client-side application (e.g., so-called "native 
  applications"), should provide means for applications to have 
  Token Binding messages, containing Token Binding IDs of various 
  application-specified Token Binding types and 
  for application-specified TLS connections, conveyed over an
  application-specified HTTPS connection, i.e., within the 
  TokenBindingMessage conveyed by the Sec-Token-Binding header
  field. 
  <list style="hanging" hangIndent="7">
    <t hangText="NOTE:">
      See <xref target="privacy-cons"/> 
      "<xref target="privacy-cons" format="title"/>",
      for privacy guidance regarding the use of 
      this functionality.
     </t>
  </list>
</t>

[ fyi/fwiw, the markup for the NOTE is as I used in RFC6797 and passed muster with the rfc-editor ]

[nharper]

I'm still confused here. Is the application something like a native app, which is acting as an https client? Are these "other connections" ones that the application makes? If both of those are true, then it's trivial to see that the application is always aware of these other connections. However, I suppose that's not what this means, so I'm wondering what the definitions are of "the application" and "other connections".

[equalsJeffH]

thx, good question. I suspect that what we meant to say in the last sentence above is..

If the endpoints are already aware of these other connections, then no additional information is being exposed.

Does that make more sense?

[nharper]

Yes, that makes more sense for that sentence. Some clarification on what the application is probably wouldn't hurt.

[equalsJeffH]

language added in below commits to clarify "application".

[nharper]

I think the new wording addresses my concerns. Thanks for updating it.