Re: ACTION-278 Hiding metadata for security reasons

Per ACTION-278

I don't see much use in writing up lots of use cases if we can't come
to consensus on at least one of them.  The following is designed to be a case
where if we can't agree on this one, we'll never agree on any others.

Use case adapted from
http://www.w3.org/2001/tag/doc/whenToUseGet.html#example-lists
(note that the GET/POST issue is completely immaterial here, I'm only
being pedantic about it because Noah got distracted by it on the telecon)

Design 1:

   1. The user is subscribed to a mailing list.
   2. The list processing software sends an email message to the user,
      including advice that the user may unsubscribe from the list, and
      giving an https: link to an unsubscribe confirmation page.
   3. The user follows this link to the confirmation page, and finds a
      form with a button to "[Confirm] your unsubscription". The form is
      to be submitted with method="POST".
   4. The user activates the [Confirm] form control.
   5. The list processing software confirms the unsubscription and
      removes the user from the list.

Someone who doesn't like putting secrets in URIs should provide an
alternative design for comparison.  It should not require that the
user keep track of a secret (password, cookie, etc) for authenticating
to the mail server.  The following is ridiculous but is the best I
could come up with that adheres to the 'good practice' given in the
metadata-in-URI finding:

Design 2:

   1. The user is subscribed message to a mailing list.
   2. The list processing software sends an email message to the user,
      providing advice that the user may unsubscribe from the list, and
      including (a) an https: link to an unsubscribe confirmation page,
      and (b) a password to enter on the confirmation page.
   3. The user follows the link to the confirmation page, and finds a
      form with an input field requesting the password (from the email
      message) and a button to "[Confirm] your unsubscription". The
      form is to be submitted with method="POST".
   4. The user copies the password from the email message and pastes
      it into the password field, and activates the [Confirm] form
      control.
   5. The list processing software confirms the unsubscription and
      removes the user from the list.

Is there any design that's less clunky than design 2 but also avoids
putting secrets in URIs?

Received on Friday, 5 February 2010 19:43:33 UTC