Re: [abfab] UI considerations document

[Sam Hartman <[e-mail]>]

>>>>> "Mark" == Mark Donnelly <[e-mail]> writes:

    Mark> All: I've spoken with Rhys about the UI considerations
    Mark> document
    Mark> (https://tools.ietf.org/html/draft-ietf-abfab-usability-ui-considerations-02),
    Mark> and I've volunteered to handle the next revision of the draft.
    Mark> I've collected the comments from the last draft and I'm
    Mark> working to incorporate them in.

    Mark> However, I have a few questions for the list.

    Mark> To start off, Alejandro Perez Mendez wrote that a reference to
    Mark> Microsoft Cardspace in section 5.1 would be nice.  Does anyone
    Mark> have one?  All I can find is a Wikipedia article, which notes
    Mark> the discontinuation of Cardspace.  (Actually, does that
    Mark> warrant the removal of the inclusion in the doc?  I'm not
    Mark> familiar with Cardspace at all.)

I definitely think it is worth mentioning; it was certainly something we
were all thinking of.
See if you find something starting at
https://technet.microsoft.com/en-us/magazine/2006.07.infocard.aspx

    Mark> Next, Ken Klingenstein asked about whether the user will want
    Mark> some degree of privacy, or a pseudo-identity.  Does the UI
    Mark> have any visibility or control over this?  As I understand the
    Mark> system, the information that is released about an identity is
    Mark> decided entirely by the IDP, and communicated to the RP.

Correct.
The overall protocol supports pseudonyms, but the UI is not currently
involved in this decision at all.

    Mark> Ken also suggests that we add a privacy considerations
    Mark> section.  If the answer to the above question is that the UI
    Mark> doesn't have any visibility into what attributes the IDP
    Mark> releases, then I'm not sure what could go in to a privacy
    Mark> considerations section for the UI document.  The privacy
    Mark> considerations I see would all apply to the greater system,
    Mark> rather than the client UI.  Does anyone have any better
    Mark> thoughts?

So, here are privacy impacts I can think of from the UI.

* Automatically choosing an identity can have privacy impact.  Think of
the Chrome incognito discussion.  Whether to let a given application
choose a given identity  for a given service has privacy impact.

* Discussion of the difference between the Kerberos model (use your
default credential when you can, giving your KDC  information about what
services you access even if they don't support Kerberos at all and our
model of requesting the user explicitly select an identity when first
talking to a service.  Note that the impact would be a bit different for
ABFAB if we used a default credential.  Rather than letting the home
IDP  know what service you are using, it would let the service know what
IDP you were using even if the IDP was inappropriate for that service.

    Mark> Finally, Ken suggested that the UI drop the concept of an NAI
    Mark> having a password change URL.  Ken argues that the helpdesk
    Mark> URL that the document already specifies would be less
    Mark> volatile, and the user could navigate from there.  I think
    Mark> this would remove a usable feature of the system, and if the
    Mark> password change URL doesn't work then the user could go
    Mark> through the helpdesk anyway.  Any thoughts?

I'd assume that if someone doesn't want a password change URI they can
not fill it in.
Also, this is an informational document.
So I tend to agree with you.