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
The text is still a little unclear on whether commit then requires subsequent connections to use "strong authentication" or just "authentication". In particular, Section 3 seems to add some confusion about whether "reasonable assurances" and "server authentication" are the same thing or not but then 5.2 sometimes uses "authenticated without "strongly authenticated". For example, this paragraph is not particularly crisp on what the requirements are (strong authentication or something else):
A commitment is not bound to a particular alternative service.
Clients are able to use alternative services that they become aware
of. However, once a valid and authenticated commitment has been
received, clients SHOULD NOT use an unauthenticated alternative
service. Where there is an active commitment, clients SHOULD ignore
advertisements for unsecured alternative services. A client MAY send
requests to an unauthenticated origin in an attempt to discover
potential alternative services, but these requests SHOULD be entirely
generic and avoid including credentials.
The text was updated successfully, but these errors were encountered:
Erik raises in post-WGLC:
The text is still a little unclear on whether commit then requires subsequent connections to use "strong authentication" or just "authentication". In particular, Section 3 seems to add some confusion about whether "reasonable assurances" and "server authentication" are the same thing or not but then 5.2 sometimes uses "authenticated without "strongly authenticated". For example, this paragraph is not particularly crisp on what the requirements are (strong authentication or something else):
The text was updated successfully, but these errors were encountered: