Hi,
In mi opinion, this draft is well written and is very comprehensive. It
has clarified my ideas on how the Identity Selector works.
I have though some comments and questions about it:
* P5. Section 4.
The draft states:
Where there is a requirement for multiple credentials to be
supported, there are of course two methods that could be employed to
configure identities and associated information:
Are you sure these are the two only options available? For example, it
could be a set of files instead of one. Or a combination of both options
(files and a program that simplifies their manipulation).
* P6. Section 5.1.
A reference to Microsoft CardSpace might be useful.
* P8. Section 6.3
The title and the first part of the section gives the reader the
impression that "addition" and "association" of identities refer to the
same concept, while in my opinion "addition" relates to the act of
introducing a new identity into the Identity Selector; and "association"
relates to the act of mapping an identity with a service. Am I right?
If so, I would rename the section to "Addition and association of an
identity". I would add a brief descritiopn of both processes at the
beggining. I would also try to homogenize the use of the term
"association" and "mapping", or explain they are synonyms (in case they
are).
If I am wrong, I think the comment might still apply, as the section may
be confusing for some readers (me included).
* P8. Section 6.3
The text states that provisioning is not the preferrred term, but it is
still used several times in the section.
* P10. Section 6.3.2.
The text says that:
Additionally, the user SHOULD be given the opportunity to:
o Indicate whether or not the identity selector should always ask
before using services with this identity - to customise the way in
which the identity selector interacts with the user with this
particular identity;
Do you refer to ask before creating a new mapping or before using an
existing mapping? (or both).
* P10. Section 6.3.2.
The text continues that end users SHOULD be given the opportunity to:
o Reject the addition of the identity completely - to allow the user
to back out of the association process in an intuitive way.
IMO, it should say "back out of the addition process" instead, as the
user is interacting with the IdP, and not associating the identity with
any service yet.
* P10. Section 6.3.3. Last paragraph
Another option would be to provision all identity information except
password. Would that make any sense? It would avoid users confusion, as
the Identity Select will still ask them for their password (at least the
first time), but trust anchors would be added automatically.
* P11. Section 6.4. Would a subsection called "Manually Triggered
Automated Modification" make any sense? Once the user updates his
password on the web portal (see Password changing URL field), the
organization may generate a provisioning file with the updated password.
This would avoid to update the password manually twice (portal and
Identity Selector), and the frustation of failing accessing a service
because you forgot to update the password on the Identity Selector once
you did on the web portal.
* P11. Section 6.5. Would an identity verification service make any
sense? The Identity Selector might include a "verify" button that would
launch the ABFAB process using the selected identity with this special
service on the IdP. If everything goes right, the identity has been
proven to be functional and well configured. This verification service
might provide (on failure) a better description to the Identity selector
on what went wrong, and so the user can inform his administrators.
* P12. Section 7 states that:
To further complicate the picture, users may wish for:
1. The identity to service mapping to be stored along with the
credential, i.e. the user should always be authenticated to a
particular service with a particular identity with no prompting.
I thought Identities and mappings where stored separatedly. While the
credential would be stored along with the Identities (as explained
above in the document), the mapping would never be stored with the
credential. In any case, it would indicate whether the credential should
be used or not.
* P14. Section 7.5.
Would it be possible to use two (or more) different identities with the
same service at the same time? E.g. access a remote SSH using my
university's identity, and in another terminal, access to the same
service using my personal identity (e.g. Google one). In that case, text
of 7.5 should be updated to "Showing the Identities currently in use".
* P15. Section 9.1
Wouldn't be enough confirmation to just being provided with the
requested service, and not being informed of any error? I'm personally
not a big fan of "success notifications" in my desktop.
Regards,
Alejandro
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
