On 12-Apr-06, at 4:01 AM, Haripriya S wrote:
1. B6 and B7 look the same.
Actually B5 and B6 are identical - oops.
B6 says Beth can share an identifier across multiple sites.
B7 says Beth can have multiple identifiers.
Should I make that clearer?
2. B11: The sentence 'Beth administers her identitier' is not very
clear? Probably an example using email or URL as an identifier can
help
here.
Agreed. I don't want to presuppose the identifier design decision
though, which is why I used the vague term 'administer'. I can't
think of a way around that... 'she does something that makes her
identifier managed by another identity agent'
3. B12: (internet cafe case) Should we call out that that she first
has
to authenticate with her identity agent?
In all these cases her identity agent should authenticate her to
ensure she is Beth. I think what you're pointing out is how the
webmail service knows that she is who she says she is? This
is also an issue with B3, which I've added some text to fix. B12
could say....
Her identity agent displays a screen informing her that webmail.com
is requesting some data, an identifier.
She provides consent and the identifier and identifier verification
data is sent to the site.
webmail.com uses the verification data to verify that Beth owns the
identifier her agent provided.
4. B13: Can we have an example of a simple privacy policy here, so
this
becomes clearer?
Good idea.
Beth visits a website to purchase some books.
The site requests some identity information, her shipping address.
Her Identity Agent warns her that satisfying the request would
contravene her established privacy policy.
The website wishes to pass her address to affilliated companies so
that they may send her valuable promotional offers,
but Beth has a privacy policy that not allow unsolicited mail to be
sent to her shipping address.
5. B14: Can the identity agent also do a similar operation if the user
wants to discontinue her relationship with a particular service
(should
the agent be able to carry out the deprovisioning/deleting of the user
information stored at the service site)?
Hmm. Interesting thought. I suspect that most Membersites would
not be interested in implementing deprovisioning/deletion... I guess
the identity agent could send a bunch of null values to the MS. I
need to think about that more.
6. B16: The identity agent should present the membership claim, not
the
user.
Thanks.
7. B21: The relationship of the identity agent to the site acting as
agency for the bank account is not clear.
Rewritten.
Beth signs up with a financial services site, BigPicture.com, which
provides an aggregate view of her finances.
To provide its service BigPicture.com requires access to her existing
bank accounts.
Beth wishes to securely provide agency rights to BigPicture.com, so
she acquires the appropriate access tokens from her existing bank
account providers and stores them with her Identity Agent.
She then presents the access tokens to BigPicture.com so that it can
access her account data.
Better?
8. B27: The last sentence is not very clear. Does it mean "the site
can
verify Adam is over 21 but cannot get any other details of Adam
including who he is (anonymous transaction?)"?
Yes. Rewritten:
Adam visits a site that requires that he prove he is over 21.
He provides the site with a claim that he is over 21, issues by the
government of his country of residence, gov.ca.
The claim contains no other information about Adam and the site is
unable to use the claim to discover more information about Adam.
Clearer?
9. B29 and B30: I understood these use-cases to mean that a user can
use either the same identifier(B29) or the same claim(B30) to
different
sites to enable them to correlate that it is the same user using their
services. Is that a right understanding?
Yes.
10. Can the user have more than one identity agent? Is this an allowed
scenario, for which use cases are required? Imagine a
organization-recommened identity agent, and a personal choice?
Yes and yes. I should add a use case that makes that clear.
Thanks for your close reading of the text and your very useful comments.
John
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
