I think this is a very dicey problem we need to solve. This is probably my first post on the "trust issue", something I would dread to venture into. Nevertheless here goes.
Living in any society, and looking into human history, trust is really a personal problem. At the end of the day, the user has to trust someone, and first of all, the user has to trust himself. Now if the user is not someone who can trust himself, then where is the onus? Is it with govt, OP, or RP? 1) Our first line of defense is the RP. After all the user is going to interact with the RP. We need some kind of policy for RP's. Eventually RP's will build their own blacklist or whitelist of OP's. I would prefer we have a mechanism for blacklists rather that whitelist. I like the idea of blacklist because all OP's can start from a clean slate and land up on a blacklist, if they have done badly. This is more or less the way anti spam mechanism has worked on the internet. 2) Our second line of defense is the OP. I think there is not much we can do here. We have to leave it to the RP's to produce the whitelist or blacklist, and do whatever they wish to do. 3) Govt. The govt's job is the provide the appropriate legal framework, to ensure RP's and OP's are working with the user's interest in mind. So my conclusion is that the onus really is on the RP. Let the RP's decide how they would like to go about this. Let them decide who they would like to trust. Our job is to provide the appropriate framework. On Tue, Dec 8, 2009 at 9:00 PM, Chris Messina <[email protected]>wrote: > This is less a technical issue than one of business logic. Any OP can lie > to an RP -- that's why they're "relying" parties! > > The point of this discussion is to specify HOW an OP would indicate that > they've already validated an email address -- or if they provide that user's > email, making the email very likely to be valid. There are no guarantees > that the user will receive messages at this address, only that the OP did > the work to confirm that it was working at some point in the past. > > Of course figuring out what such an attribute means is important (do they > host the email? When and how did they verify it?) but for now we have > several OPs who will a user's email as a convenience to the RP and it would > be very valuable to not have to force the user to RE-verify their email to > EVERY RP. > > Again, it's up to the RP to decide what to do with this attribute, but > defining it upfront is a useful effort since OPs already have this data! > > Chris > > Sent from my iPhone 2G > > > On Dec 8, 2009, at 1:57, Joseph A Holsten <[email protected]> > wrote: > > I understand the desire to say that the email is verified, but it strikes >> me as a bit like the urgent priority field in email. "No email provided" vs >> "This is the user's email" vs "This is Really the User's Email and I Mean >> It". Unless it means "This is the user's email, I've done due diligence, and >> you can hold me legally liable." Everything else boils down to understanding >> what the OP means when they make an assertion. >> >> If you really want a verified flag/timestamp/zero-knowledge-proof, perhaps >> you have a better idea about the interaction flow when things aren't >> verified to 100% certainty. Would the OP require the user to verify their >> email before allowing them to authenticate? Leave it up to the RP to verify? >> What if the OP says they're certain but the RP doesn't actually trust them? >> What happens when the OP says they've verified, but not 100% certain? Do you >> expect different RPs to make different decisions in these circumstances? How >> would they choose? >> >> I'm assuming we're not talking about RPs that have a significant legal / >> medical / financial interest in accurate assertions, because that's legal >> liability / consent / know your customer and you'll need more than a >> timestamp+i-mean-it for that. >> -- >> j >> >> On Dec 7, 2009, at 10:36 PM, Allen Tom wrote: >> >> I’d recommend using a timestamp indicating when it was last verified, >>> with a special value to indicate that the OP is also the email provider and >>> has 100% certainty. (perhaps just setting the verification time==now is >>> sufficient) >>> >>> Allen >>> >>> >>> On 12/7/09 8:29 PM, "Chris Messina" <[email protected]> wrote: >>> >>> Sounds like something to add to PoCo... perhaps something as simple as a >>>> "verified" boolean added to email addresses? >>>> >>>> http://portablecontacts.net/draft-schema.html#anchor4 >>>> >>>> Chris >>>> >>>> On Mon, Dec 7, 2009 at 8:25 PM, Brian Kissel <[email protected]> >>>> wrote: >>>> >>>>> +1 on email address metadata, many RPs definitely want this. >>>>> >>>>> Cheers, >>>>> >>>>> Brian >>>>> ___________ >>>>> >>>>> Brian Kissel >>>>> CEO, JanRain - WebID and Social Publishing for User Engagement >>>>> Email: [email protected] Cell: 503.866.4424 Fax: >>>>> 503.296.5502 >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: [email protected] [mailto:openid-specs- >>>>> [email protected]] On Behalf Of Allen Tom >>>>> Sent: Monday, December 07, 2009 7:46 PM >>>>> To: Peter Watkins; Chris Obdam; [email protected] >>>>> Subject: Re: Yahoo available AX attrs >>>>> >>>>> Oops - I clicked send too early. >>>>> >>>>> The bad UX with AX is the security warning that most browsers display >>>>> when >>>>> POSTing a form from HTTPS to HTTP, which is the case when the Yahoo OP >>>>> returns a lot of attributes. AX attribute names are excessively long, >>>>> so >>>>> it's very likely that using different attribute names for >>>>> first/last/middle >>>>> name will cause the response to be returned via POST. (2KB is the >>>>> cutoff >>>>> point) >>>>> >>>>> With regards to email address - unless we're 100% sure about the email >>>>> address, we'd like to return metadata about the email address. >>>>> Specifically, >>>>> we'd like to indicate whether or not the email address was verified, >>>>> and if >>>>> so, when it was verified. This is definitely something that we'd like >>>>> to get >>>>> in to AX 2.0. >>>>> >>>>> Allen >>>>> >>>>> >>>>> >>>>> On 12/7/09 7:39 PM, "Allen Tom" <[email protected]> wrote: >>>>> >>>>> > It definitely makes sense to use different attributes for >>>>> givennanme/surname >>>>> > so that RPs don't have to parse the string, and a few other RPs have >>>>> also >>>>> > asked for it. Our initial goal for our AX implementation was just to >>>>> match >>>>> > SREG, and SREG only has a single openid.sreg.fullname attribute. >>>>> > >>>>> > We'll add support for separate first/last/middle/suffix attributes in >>>>> a >>>>> > followup release - probably early next year. I do hope that we're >>>>> able to >>>>> > standardize the attribute names, and also keep them short and >>>>> compact. If you >>>>> > ask for all our supported attributes, the response will exceed 2KB, >>>>> which >>>>> > requires that the response is returned via POST, causing a really bad >>>>> UX. >>>>> > >>>>> > With regards to email address - we'd like to be able to return >>>>> metadata about >>>>> > the email address w >>>>> > >>>>> > >>>>> > >>>>> > On 12/7/09 7:25 AM, "Peter Watkins" <[email protected]> wrote: >>>>> > >>>>> >> On Mon, Dec 07, 2009 at 09:16:46AM +0100, Chris Obdam wrote: >>>>> >>>> Chris (Obdam) - which additional attributes would you like to see >>>>> >>>> available? The attributes that we’ll be adding early next year >>>>> will include >>>>> >>>> Yahoo Profile URL and account creation date. A bunch of people >>>>> have asked >>>>> >>>> for Flickr Photos URL and Upcoming Profile URL, so we’ll probably >>>>> get >>>>> >>>> around >>>>> >>>> to adding those too. >>>>> >>> I would like to access every attr specified in de AXschema? :-) >>>>> >>> >>>>> >>> In my Yahoo profile i have provided my address (home and work). I >>>>> would like >>>>> >>> to use those in a sign form somewhere else. >>>>> >>> Same goes for my phone numbers. >>>>> >> >>>>> >> So would I. One of the simpler goals of our Single Sign On is >>>>> prepopulating >>>>> >> form fields; having postal address and phone number would be a help. >>>>> >> >>>>> >> I'd also like to see First and Last names available as separate >>>>> attributes, >>>>> >> otherwise we're trying to intelligently split both "Mary Jane >>>>> Parker" and >>>>> >> "Malcom Mac Murray". >>>>> >> >>>>> >> Also I would prefer that you give us the user's *primary* email >>>>> address. In >>>>> >> my Yahoo profile, my Yahoo email address is flagged as "Share with >>>>> no one" >>>>> >> and I have a different email address flagged as primary, but your AX >>>>> sends >>>>> >> my yahoo email address. That's bad from usability in part because I >>>>> very, >>>>> >> very seldom check my Yahoo email inbox. >>>>> >> >>>>> >> The Yahoo website attribute would also be nice to have; as we start >>>>> >> building more "social" features on our sites, it would be nice to >>>>> make >>>>> >> it easier for our users to share links to their primary web >>>>> presences, >>>>> >> although I can understand if Yahoo management prefers to only expose >>>>> the >>>>> >> Profile URL for business reasons. >>>>> >> >>>>> >> Thanks, >>>>> >> >>>>> >> Peter >>>>> >> >>>>> >>>>> _______________________________________________ >>>>> specs mailing list >>>>> [email protected] >>>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>>> _______________________________________________ >>>>> specs mailing list >>>>> [email protected] >>>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>>> >>>> >>>> >>>> _______________________________________________ >>> specs mailing list >>> [email protected] >>> http://lists.openid.net/mailman/listinfo/openid-specs >>> >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > -- http://hi.im/santosh
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
