[OpenID] Windows Live ID OpenID CTP Status Update (August 2009)
Jorgen Thelin
FYI, the Live ID Team has posted a blog post giving a status update on the Live ID OpenID Provider Community Tech Preview and some of the lessons learned (particularly around UI / user experience) which you guys may find of interest.
http://winliveid.spaces.live.com/blog/cns!AEE1BB0D86E23AAC!1791.entry
I bet you all thought we had forgotten about this stuff ;-), but we are actively working on the production OP release for Live ID users.
Unfortunately I cannot publicly share any specific schedule details at this stage. Stay tuned though :)
- Jorgen
Peter Williams
There seems resistance by the portals to participating in (user directed) vanity delegation (using third parties). More and more, folks are citing (vague) "liability" issues.
We seemed to be left with rp sites simply enabling plural account linking, to retain some measure of user control and autonomy from an overbearing idp.
Of course, there is also the clickpass / ping identity / azure acs proxy model, based on assertion relaying. For ping, translation is a hidden cloud matter: for clickpass it's an explicit relaying ui: for azure, it's the whole role/privilege resource sts story.
On Aug 27, 2009, at 1:37 PM, "Jorgen Thelin" <jth...@microsoft.com<mailto:jth...@microsoft.com>> wrote:
FYI, the Live ID Team has posted a blog post giving a status update on the Live ID OpenID Provider Community Tech Preview and some of the lessons learned (particularly around UI / user experience) which you guys may find of interest.
<http://winliveid.spaces.live.com/blog/cns!AEE1BB0D86E23AAC!1791.entry>http://winliveid.spaces.live.com/blog/cns!AEE1BB0D86E23AAC!1791.entry
I bet you all thought we had forgotten about this stuff ;-), but we are actively working on the production OP release for Live ID users.
Unfortunately I cannot publicly share any specific schedule details at this stage. Stay tuned though :)
- Jorgen
_______________________________________________
general mailing list
gen...@lists.openid.net<mailto:gen...@lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-general
_______________________________________________
general mailing list
gen...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
David Recordon
--David
Chris Messina
Chris Messina
Open Web Advocate
Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina
Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net
This email is: [ ] bloggable [X] ask first [ ] private
Breno de Medeiros
research in the site:
https://sites.google.com/site/oauthgoog/
--
--Breno
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
Chris Messina
Peter Williams
On Aug 27, 2009, at 3:55 PM, "Chris Messina" <chris....@gmail.com<mailto:chris....@gmail.com>> wrote:
Fair enough. It is a little overwhelming, but I suppose that's a good thing.
Is this still your most current thinking?
Chris
On Thu, Aug 27, 2009 at 3:03 PM, Breno de Medeiros <<mailto:br...@google.com>br...@google.com<mailto:br...@google.com>> wrote:
Google regularly shares the results of our experiences and our
research in the site:
On Thu, Aug 27, 2009 at 2:56 PM, Chris Messina<<mailto:chris....@gmail.com>chris....@gmail.com<mailto:chris....@gmail.com>> wrote:
> This post is very useful, and one of the more elaborate from one of the
> majors. I want to commend Microsoft for providing the amount of information
> that they did, and for sharing their findings (not with data, but still, the
> takeaways are generally useful).
> I would be very happy if Facebook, Yahoo, and Google all did the same.
> Clearly folks have had some questions and challenges dealing with OpenID on
> Google Apps for Your Domain, and it would be useful to understand where the
> confusion is coming from so that we could work to address it.
> In general, I find Microsoft's experience sobering — from both a privacy and
> usability perspective. The things that are valued by the UCI community seem
> to need to be jettisoned left and right because regular folks just don't
> grok it. These things are important to consider — and merely complaining
> about the loss of such features or the diminishment of certain priorities
> does us no good.
> Allen Tom, Steven Jackson and (I think) Luke Shepard have all been working
> on the user experience of OpenID for several months now, and it's unclear to
> me what the path to seeing that work adopted or reviewed is.
> Microsoft is clearly making progress here — and it would behoove the OpenID
> community, I believe, to take note of their lead and consider how we can
> learn more about how OpenID is actually performing in the wild and how it's
> being adopted and used (or not).
> Chris
>
>>
>> Great, thanks for the update!
>>
>> --David
>>
>> > FYI, the Live ID Team has posted a blog post giving a status update on
>> > the
>> > Live ID OpenID Provider Community Tech Preview and some of the lessons
>> > learned (particularly around UI / user experience) which you guys may
>> > find
>> > of interest.
>> >
>> >
>> >
>> > I bet you all thought we had forgotten about this stuff ;-), but we are
>> > actively working on the production OP release for Live ID users.
>> >
>> >
>> >
>> > Unfortunately I cannot publicly share any specific schedule details at
>> > this
>> > stage. Stay tuned though :)
>> >
>> >
>> >
>> > - Jorgen
>> >
>> >
>> >
>> > _______________________________________________
>> > general mailing list
>> > <http://lists.openid.net/mailman/listinfo/openid-general> http://lists.openid.net/mailman/listinfo/openid-general
>> >
>> >
>> _______________________________________________
>> general mailing list
>> <mailto:gen...@lists.openid.net> gen...@lists.openid.net<mailto:gen...@lists.openid.net>
>> <http://lists.openid.net/mailman/listinfo/openid-general> http://lists.openid.net/mailman/listinfo/openid-general
>
>
> --
> Chris Messina
> Open Web Advocate
>
> Follow me on Twitter: <http://twitter.com/chrismessina> http://twitter.com/chrismessina
>
> Citizen Agency: <http://citizenagency.com> http://citizenagency.com
> Diso Project: <http://diso-project.org> http://diso-project.org
> OpenID Foundation: <http://openid.net> http://openid.net
> This email is: [ ] bloggable [X] ask first [ ] private
>
> _______________________________________________
> general mailing list
> <http://lists.openid.net/mailman/listinfo/openid-general> http://lists.openid.net/mailman/listinfo/openid-general
>
--
--Breno
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
--
Chris Messina
Open Web Advocate
Follow me on Twitter: <http://twitter.com/chrismessina> http://twitter.com/chrismessina
Citizen Agency: <http://citizenagency.com> http://citizenagency.com
Diso Project: <http://diso-project.org> http://diso-project.org
OpenID Foundation: <http://openid.net> http://openid.net
This email is: [ ] bloggable [X] ask first [ ] private
_______________________________________________
general mailing list
Peter Williams
Google: no it's not: email address is king. Pah to you, and your URL axiom.
That's what I read.
On Aug 27, 2009, at 3:55 PM, "Chris Messina" <chris....@gmail.com<mailto:chris....@gmail.com>> wrote:
Is this still your most current thinking?
Chris
On Thu, Aug 27, 2009 at 3:03 PM, Breno de Medeiros <<mailto:br...@google.com>br...@google.com<mailto:br...@google.com>> wrote:
Google regularly shares the results of our experiences and our
research in the site:
On Thu, Aug 27, 2009 at 2:56 PM, Chris Messina<<mailto:chris....@gmail.com>chris....@gmail.com<mailto:chris....@gmail.com>> wrote:
> This post is very useful, and one of the more elaborate from one of the
> majors. I want to commend Microsoft for providing the amount of information
> that they did, and for sharing their findings (not with data, but still, the
> takeaways are generally useful).
> I would be very happy if Facebook, Yahoo, and Google all did the same.
> Clearly folks have had some questions and challenges dealing with OpenID on
> Google Apps for Your Domain, and it would be useful to understand where the
> confusion is coming from so that we could work to address it.
> In general, I find Microsoft's experience sobering — from both a privacy and
> usability perspective. The things that are valued by the UCI community seem
> to need to be jettisoned left and right because regular folks just don't
> grok it. These things are important to consider — and merely complaining
> about the loss of such features or the diminishment of certain priorities
> does us no good.
> Allen Tom, Steven Jackson and (I think) Luke Shepard have all been working
> on the user experience of OpenID for several months now, and it's unclear to
> me what the path to seeing that work adopted or reviewed is.
> Microsoft is clearly making progress here — and it would behoove the OpenID
> community, I believe, to take note of their lead and consider how we can
> learn more about how OpenID is actually performing in the wild and how it's
> being adopted and used (or not).
> Chris
>
>>
>> Great, thanks for the update!
>>
>> --David
>>
>> > FYI, the Live ID Team has posted a blog post giving a status update on
>> > the
>> > Live ID OpenID Provider Community Tech Preview and some of the lessons
>> > learned (particularly around UI / user experience) which you guys may
>> > find
>> > of interest.
>> >
>> >
>> >
>> > I bet you all thought we had forgotten about this stuff ;-), but we are
>> > actively working on the production OP release for Live ID users.
>> >
>> >
>> >
>> > Unfortunately I cannot publicly share any specific schedule details at
>> > this
>> > stage. Stay tuned though :)
>> >
>> >
>> >
>> > - Jorgen
>> >
>> >
>> >
>> > _______________________________________________
>> > general mailing list
>> >
>> >
>> _______________________________________________
>> general mailing list
>> <http://lists.openid.net/mailman/listinfo/openid-general> http://lists.openid.net/mailman/listinfo/openid-general
>
>
> --
> Chris Messina
> Open Web Advocate
>
> Follow me on Twitter: <http://twitter.com/chrismessina> http://twitter.com/chrismessina
>
> Citizen Agency: <http://citizenagency.com> http://citizenagency.com
> Diso Project: <http://diso-project.org> http://diso-project.org
> OpenID Foundation: <http://openid.net> http://openid.net
> This email is: [ ] bloggable [X] ask first [ ] private
>
> _______________________________________________
> general mailing list
>
--
--Breno
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
--
Chris Messina
Open Web Advocate
Follow me on Twitter: <http://twitter.com/chrismessina> http://twitter.com/chrismessina
Citizen Agency: <http://citizenagency.com> http://citizenagency.com
Diso Project: <http://diso-project.org> http://diso-project.org
OpenID Foundation: <http://openid.net> http://openid.net
This email is: [ ] bloggable [X] ask first [ ] private
_______________________________________________
general mailing list
Breno de Medeiros
(typically based on usernames or email addresses) can integrate OpenID
with good usability.
A variant of that is to use "Email address or URL:" and have a uni-box
for login.
Chris Messina
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net
Johannes Ernst
Luke Shepard
It’s worth highlighting this bit from the Microsoft post:
“OpenID does not support a network sign-out function as part of its protocol, which can mean that users are left in a state that differs from what they might assume. For example, Windows Live ID users who sign out of an OpenID site might expect to be completely signed out of their account, because that is what happens on all other Windows Live ID-enabled sites.”
Eric Sachs
OpenID does not support a network sign-out function as part of its protocol, which can mean that users are left in a state that differs from what they might assume. For example, Windows Live ID users who sign out of an OpenID site might expect to be completely signed out of their account, because that is what happens on all other Windows Live ID-enabled sites.
Chris Messina
Allen Tom
some wireframes to the public wiki awhile back.
http://wiki.openid.net/Details-of-UX-Best-Practices-for-RPs
http://wiki.openid.net/f/OpenID+RP+06162009.pdf
The User Interface Extension is also nearly complete, with Google
already having support for it in production. Yahoo will also be
launching support for it in the very near future. I expect to see the
success rate for Yahoo OpenID to increase significantly after the UI
upgrade.
Allen
Chris Messina wrote:
>
> Allen Tom, Steven Jackson and (I think) Luke Shepard have all been
> working on the user experience of OpenID for several months now, and
> it's unclear to me what the path to seeing that work adopted or
> reviewed is.
>
_______________________________________________
Peter Williams
I swear I read recently that it was being dropped, in an upcoming UI redesign based on a UX study.
Yahoo folks can confirm: is the feature being dropped, or being retained?
Is it part of the strategy to
(a) let users pick available aliases?
(b) let users direct which alias is released to which RP?
I don't really see it as particularly important one way or the other; except in the determining which elements of the mission (re privacy/user centric features) are or are not being pursued by the giant corporations; which are being messaged or dropped by the Foundation.
.
-----Original Message-----
From: Peter Watkins [mailto:pet...@tux.org]
Sent: Thursday, August 27, 2009 9:23 PM
To: Peter Williams
Cc: openid-...@lists.openid.net
Subject: Re: [OpenID] Windows Live ID OpenID CTP Status Update (August 2009)
Peter Williams wrote:
> So the experiment with directed I'd to allow users to release different identity urls/synonyms to subsets of relying part sites has failed. Even yahoo has withdrawn, I believe.
>
Where'd you get that impression? I just now logged in to Yahoo and
verified that I can still use the "OpenID Home" link to get the UI for
requesting additional "me.yahoo.com" identifiers, and their OP login
flow still lets me choose between the very ugly unique ID they first
created for me, and the slightly less ugly identifier that I created. So
they still seem to support directed identity and allowing users to
create a set of alternative identifiers.
Or maybe I'm not understanding what you're saying. It wouldn't be the
first time. ;-)
Windows Live folks -- thanks for sharing. I look forward to digesting
this tomorrow. And I look forward to seeing your final solution. I do
hope it, like the offerings from Yahoo! and Google (and, if I recall
correctly, the CTP setup), will allow for 100% https usage, so we can
trust the process. If so, I'm sure we'll add an easy "Login with Windows
Live ID" button to our RP site. If not, we won't accept Live as an OP,
even if a user is geeky enough to enter a valid URL in the OpenID text box.
-Peter
Peter Watkins
> So the experiment with directed I'd to allow users to release different identity urls/synonyms to subsets of relying part sites has failed. Even yahoo has withdrawn, I believe.
>
verified that I can still use the "OpenID Home" link to get the UI for
requesting additional "me.yahoo.com" identifiers, and their OP login
flow still lets me choose between the very ugly unique ID they first
created for me, and the slightly less ugly identifier that I created. So
they still seem to support directed identity and allowing users to
create a set of alternative identifiers.
Or maybe I'm not understanding what you're saying. It wouldn't be the
first time. ;-)
Windows Live folks -- thanks for sharing. I look forward to digesting
this tomorrow. And I look forward to seeing your final solution. I do
hope it, like the offerings from Yahoo! and Google (and, if I recall
correctly, the CTP setup), will allow for 100% https usage, so we can
trust the process. If so, I'm sure we'll add an easy "Login with Windows
Live ID" button to our RP site. If not, we won't accept Live as an OP,
even if a user is geeky enough to enter a valid URL in the OpenID text box.
-Peter
_______________________________________________
SitG Admin
>
>"Chris"
>
>And the system responds: "Chris who?"
>
>I'm only partially joking.
Google sometimes guesses what I'm trying to look for and offers
autocomplete suggestions as I'm typing. I dislike this because, as it
reveals, Google is having my keystrokes sent to them in real time.
The privacy concern with a RP is that it would reveal the existence
of other names (commonly associated with Chris, to continue your
example) known to that system. Especially since I wouldn't (at that
time) even be *verified* as having (any claim to) the name Chris
myself, because the system wouldn't be sure *who* I was (but would be
trying to help me figure it out). I could just type in names, whoever
I was after, and hope to find them. I just know their first name? Is
it an especially *uncommon* first name? Oh, good - well, then, let me
see if any popular sites know them by (an account associated with)
their *last* name.
I do think it's a nice feature, but I don't see it going any further
than "Your username is 'factoryjoe' at which site?".
-Shade
Peter Williams
interesting to conceive of a world on which one can learn from web
crawling the "data entry" patterns of users, and thus collect the data
to spoof this bio signal.
Add a col to the rainbow table, of the passwords, expressed as
personal keystroke patterns. Then start phishing...
What would the openid antiphishing countermeasure be?
On Aug 28, 2009, at 8:43 AM, "SitG Admin" <sysa...@shadowsinthegarden.com
Jorgen Thelin
Yes, that is one of our core requirements for the production release :)
We will also provide a "Login with Windows Live ID" type button for RP's to use.
-----Original Message-----
From: openid-gene...@lists.openid.net [mailto:openid-gene...@lists.openid.net] On Behalf Of Peter Watkins
Sent: Thursday, August 27, 2009 9:23 PM
To: Peter Williams
Cc: openid-...@lists.openid.net
Subject: Re: [OpenID] Windows Live ID OpenID CTP Status Update (August 2009)
Peter Williams
consider publishing the root cert for https-based discovery and op
identifier endpoint interworking (also) as self signed certs (from a
https url chaining to a common public ca).
Public ca typically impose relying party agreements (on cert users,
and the "protected" transactions). We don't want conflict of legal
controls, where the rp is under 1 set of legal obligations concerning
reliance during association formation and discovery, the user is under
another set imposed by the op, and a third set of obligations from the
ca serving the rp website will probably seek to govern further with
yet more rules (that may well conflict with those projected by the ca
serving the op, and/or the terms of use set by the resource site
itself).
Unlike the https launch (which had years of careful 3-party legal
design behind it), openid has no (multi party) legal design or even a
framework for resolving conflicts of reliance limits, reliance
policies, reliance obligations, ...
Though this could be solved by requiring 1 ca throughout the entire
sequence flow, that unfortunately conflicts with the decentralized goal.
On Aug 28, 2009, at 11:14 AM, "Jorgen Thelin" <jth...@microsoft.com>
wrote:
Jorgen Thelin
"All hands -- Shields up, and brace for impact!" :)
First off, for context -- there are probably ZERO "mainstream users" on this list, so this is a very biased sample when evaluating functionality for mainstream users! How mainstream users think and what experience they need is almost certainly the exact opposite of what the super-power-users on this list want.
Hypothesis: <heresy> Directed identity choices don't work for *mainstream* users </heresy>
- Looking at the Live ID CTP experience, we found that most users (even very tech literate ones) just don't know the difference between a global / unique identifier and an "anonymous" / pairwise identifier.
- Those users don't know when they should be using which type, or really much about why.
- The few that do understand the difference will pretty much always choose a single identifier type according to their personal preferences -- some people strongly favor having correlatable identifiers across all services, and others absolutely abhor that idea.
- Most users will always go with the default selection if they don't understand the question, or else they will cancel and refuse to answer. They rely on the IdP to "do the right thing" on their behalf.
- We found it pretty much impossible to craft any explanatory text to explain the different types of identifiers, or provide the necessary privacy guidance to help users decide which to use.
Our conclusion is that full directed identity functionality is something that the folks on this list clearly care about, but is a model that just doesn't register with or help the other 99.999999% of any large user base.
"logic clearly dictates that the needs of the many outweigh the needs of the few"
http://www.imdb.com/title/tt0084726/quotes
- Jorgen
Johannes Ernst
There was a reason we started LID from the perspective of "I want to
have a public identifier that I can use everywhere."
The counter-argument is a "code as law" argument. If we can hide many
things under the covers, e.g. the actual identifier as the use cases
have evolved, can't we hide "automatic privacy" under the covers, too?
Personally, I have never seen an end-to-end design for that, but that
doesn't mean there can't be one?!?
George Fletcher
making a decision is almost impossible. However, what about cases where
an RP knows it only wants a pair-wise, pseudonymous identifier? This
takes the decision out of the user's realm and allows the RP to specify
(or at least label it as a preference).
Another option might be to remove the concept of "semantics" from the
identifier and just use it as a means of discovery. This means users
don't have to decide anything. An RP would not then "display" the OpenID
but rather use it as a protocol mechanism to discovery the user's OP.
From my experience, overloading an identifier with multiple semantics
only leads to complications down the road. It starts out seeming like a
simplifying concept but in the end just causes problems.
Thanks,
George
SitG Admin
>design behind it), openid has no (multi party) legal design or even a
>framework for resolving conflicts of reliance limits, reliance
>policies, reliance obligations, ...
>
>Though this could be solved by requiring 1 ca throughout the entire
>sequence flow, that unfortunately conflicts with the decentralized goal.
In a previous post, I suggested that OP's, in future, may automate
the legalities on behalf of their users; certainly, this is an
opportunity for OP's favoring decentralization to push that factor,
through favoring some legal designs over others . . . it's an
interesting world to imagine, where success is determined by
RP's/CA's willingness to embrace one political model over another,
and popularity by how well those OP's educate users about the
freedoms they give up going with decentralization-unfriendly OP's
that offer wider compatibility!
-Shade
Allen Tom
> I swear I read recently that it was being dropped, in an upcoming UI redesign based on a UX study.
>
> Yahoo folks can confirm: is the feature being dropped, or being retained?
>
Yahoo fully supports letting users chose personalized OpenIDs. Users can
use their Flickr Photos URL as an OpenID, or chose a personalized alias
of the form https://me.yahoo.com/<your personalized alias>
While this feature probably appeals to many of the readers of this
mailing list, Yahoo's usability studies show that most mainstream Yahoo
users are really confused by the concept of choosing an OpenID when
signing into an RP. Most users think that they're just signing into the
the RP with their Yahoo account, similar to how they sign into the Yahoo
network with their Yahoo ID.
Based on our usability research, we have de-emphasized the flow for
setting up a customized Yahoo OpenID. If you'd like to setup an
customized OpenID, just go to http://openid.yahoo.com and click the big
yellow button to set one up.
Allen
Allen Tom
> Hypothesis: <heresy> Directed identity choices don't work for *mainstream* users </heresy>
>
that directed identity doesn't work for most technically sophisticated
users. Obviously, the folks on this list are an exception.
The value proposition for OpenID is that users can sign into an RP with
an account that they already have. People who have multiple online
identities or personas already know how to have multiple accounts for
each persona, and already switch between accounts when they want to
project a different identity.
Allen
Nate Klingenstein
>> Hypothesis: <heresy> Directed identity choices don't work for
>> *mainstream* users </heresy>
>>
> This is not heresy, this is the truth. I'd go even further and claim
> that directed identity doesn't work for most technically
> sophisticated users. Obviously, the folks on this list are an
> exception.
I'm not convinced at all that that is truth.
If we look at the UK Federation, for example, which I would consider
as serving both a very large user base and a wide variety of services,
eduPersonTargetedID(e.g. directed identity expressed in SAML 1.1) is
one of the core attributes. Many of the largest services rely either
on directed identity alone or directed identity and institutional
affiliation.
http://www.ukfederation.org.uk/content/Documents/AttributeUsage
This may have something to do with differential privacy laws or user
interfaces, or different priorities in deployment. But with evidence
in hand that a lot of services and a lot of identity sources prefer to
use directed identity in a very large deployment, it's hard for me to
agree with the conclusions you and Jorgen have reached.
I think that George's statement that informed RP's and OP's can make
appropriate decisions in identifier usage is right on.
Nate.
Brian Kissel
At present, site users like this best as do the RPs we've worked with. Maybe as time progresses and we can collectively educate the market that OpenID is the platform behind this SSO functionality, we can "train the users" to do something that is more extensible or creates a richer/better user experience, but that time is down the road. Right now I think we should all be focused doing whatever it takes to get more RPs to deploy the technology and more end users to take advantage of it, and ultimately demand it.
Cheers,
Brian
___________
Brian Kissel
CEO, JanRain - OpenID-enable your websites, customers, partners, and employees
5331 SW Macadam Ave., Suite 375, Portland, OR 97239
Email: bki...@janrain.com Cell: 503.866.4424 Fax: 503.296.5502
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4378 (20090828) __________
The message was checked by ESET NOD32 Antivirus.
John Bradley
Date: Fri, 28 Aug 2009 15:44:13 -0700
From: Allen Tom <at...@yahoo-inc.com>
Subject: Re: [OpenID] Windows Live ID OpenID CTP Status Update (August
2009)
To: Jorgen Thelin <jth...@microsoft.com>,
"openid-...@lists.openid.net" <openid-...@lists.openid.net>
Message-ID: <4A985DBD...@yahoo-inc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Jorgen Thelin wrote:Hypothesis: <heresy> Directed identity choices don't work for *mainstream* users </heresy>
This is not heresy, this is the truth. I'd go even further and claim
that directed identity doesn't work for most technically sophisticated
Allen Tom
Enter your email address or Profile URL: [...................]
Allen
John Bradley wrote:
>
>
> A better UI is needed however.
>
_______________________________________________
Peter Williams
It’s a bridge too far, John. Take the big win, and move on to bigger concepts later. Don’t oversell it, at this point.
“WebSSO with auto-pop of signup forms. “
That’s what folks want - and see in openid. Nothing else is required - to join SSL on the web security pantheon.
Just deliver the original openid1 concept, with that luxurious openid2 technology.
John Bradley
address to whoever asks for it is a good idea.
I understand the attraction of using email address as it is the
identifier that requires the least explanation.
Would having someone enter there email or identity provider be too
confusing for people.
I always thought your me.yahoo.com was a good model.
Where we are going to hit serious problems first is with services like
openID for google domains, and OPX now from JainRain.
The current NASCAR doesn't have enough space for thousands of OPs.
One approach is to come up with a way for users to advertise to RP who
there preferred providers are.
That way the RP can customize the UI more appropriately for the user.
One approach would be a browser plugin that injects java script into
the page.
Another would be to have a centralized discovery service, that a RP
could query via JS in the browser.
OP's would register themselves with the service.
The latter certainly has privacy issues.
John B.
John Bradley
John Bradley
Combining it with FOAF is interesting.
I suspect that getting people at large to configure client certs is
unlikely.
That was one of the things that lead to the development of Information
cards.
It is worth considering amongst the options. However I personally
gave up on that approach a good while ago.
John B.
On 29-Aug-09, at 2:27 PM, Story Henry wrote:
> If you want one click authentication that works with most current
> browsers, that does not require a username, nor a password, and
> where the browser offers the user a popup to select his idenity then
> have a look at foaf+ssl.
>
> http://esw.w3.org/topic/foaf+ssl
>
> An example implementation is http://foaf.me/
> which will create a certificate for you in Firefox, Safari and Opera
> after you created your foaf file. (We could get IE to work too but
> it requires a bit of ActiveX (no download required) hacking.
>
> Henry
Story Henry
browsers, that does not require a username, nor a password, and where
the browser offers the user a popup to select his idenity then have a
look at foaf+ssl.
http://esw.w3.org/topic/foaf+ssl
An example implementation is http://foaf.me/
which will create a certificate for you in Firefox, Safari and Opera
after you created your foaf file. (We could get IE to work too but it
requires a bit of ActiveX (no download required) hacking.
Henry
On 29 Aug 2009, at 20:21, John Bradley wrote:
Story Henry
On 29 Aug 2009, at 20:44, John Bradley wrote:
> Using SSL client auth seemed like a good idea to me 10 years ago.
>
> Combining it with FOAF is interesting.
>
> I suspect that getting people at large to configure client certs is
> unlikely.
It turns out that that is as easy as clicking a button. Firefox,
Safari and Opera use the until now undocumented keygen tag now in html5
http://dev.w3.org/html5/spec/Overview.html#the-keygen-element
As I said you can try that with http://foaf.me
1. fill in the form
2. create your foaf file
3. click the create cert button
foaf.me can be improoved a lot. But it shows the potential here.
You can get the same with as keygen with ActiveX in IE. We are looking
for VB people to help us test that.
Henry
Story Henry
- in 10 minutes at HAR
http://blogs.sun.com/bblfish/entry/camping_and_hacking_at_har2009
- in 45 minutes at FrOSCon
http://blogs.sun.com/bblfish/entry/froscon_the_free_and_open
Henry
Peter Williams
If the ides of march put ssl client certs together with FOAF and Lampson's trust chain discovery logic, Ceasar may yet take Rome from Pompey.
Good old fashioned ssl client certs (now with url names) could WELL do to infocards what openid just did to saml2.
I'm very much on the fence with infocarda. And - as always - I'm rather wary of the well-funded lobbys. Its trusted client is an incredible assurance luxury, but therefore has headaches and control issues. We all know client certs; simple, & obvious.
It took over 15+ years to get (server) certs from standard to market. (the patent almost expired on us!) If it takes 10 more to do it for client certs, that are now patent free, so be it. A few million USG users use SSL client certs every day ...for the last 10 years. They are (necessarily) a part of the NSA version of SSL key agreement handshake.
-----Original Message-----
From: openid-gene...@lists.openid.net [mailto:openid-gene...@lists.openid.net] On Behalf Of John Bradley
Sent: Saturday, August 29, 2009 11:44 AM
To: Story Henry
Cc: openid-...@lists.openid.net
Subject: Re: [OpenID] Windows Live ID OpenID CTP Status Update (August 2009)
SitG Admin
>
>That's what folks want - and see in openid.
They don't want decentralization because they don't (fore)see a
(future) need for it? If a major provider went down, of course, they
would - and especially, then, if the opportunity were taken to stress
how vulnerable this reliance on a single provider must be. The trick
is to stress this lesson without actually causing people the loss of
their provider, nor requiring a large one to go down.
What comes to mind is the 1938 broadcast of War Of The Worlds, but
this caused some panic at the time, so perhaps repeating Welles'
technique here would not be advisable.
-Shade still thinks it would be cool, though :)
Peter Williams
http://foaf.com/peter.rdf#me#<hash> ?
Let's assume that the webid in the (self-signed) client cert's extended subject name (uri variety) has such a hash fragment - and that acts in addition to the fragment label (#me) that more typically denotes the asserted subject.
Lets assume now that the value of the fragment is hash(foaffile).
Could we make an SSL server's act of resolving the webid+fragment now validate the integrity of the referenced foaf data? ...much as one does with signed XRD today - when references in the signed info of an xml dsig are typically validated using hashes?
To implement, one simply borrows the reference resolver/digester routines from the existing xml dsig API, surely?
Of course, that objects in the foaf file denoted by "http://...#me" may also contain the assertion of the subject's openid "account" - a value such as http://openid.yahoo.com, perhaps.
Upon receiving the access request, now the SSL server might solicit an assertion from the OP, in order to locally link the webid (in one domain space) and openid (in another domain space).
All we really need do to achieve this, surely, is put the users webid in the sreg.homepage store attribute.
I'm never sure if folks desire to "harmonize" the various almost-mature identity efforts are real, or just lobbyist spin. If they are real, there is SO much we can do, when folks combine!
Juts think about it. 3 outsider technologies (SSL client certs, FOAF, openid2) combining .. to define a version of https now fit for the semweb!!
-----Original Message-----
From: openid-gene...@lists.openid.net [mailto:openid-gene...@lists.openid.net] On Behalf Of Story Henry
Sent: Saturday, August 29, 2009 11:52 AM
To: John Bradley
Cc: openid-...@lists.openid.net
Subject: Re: [OpenID] Windows Live ID OpenID CTP Status Update (August 2009)
Story Henry
On 30 Aug 2009, at 04:39, Peter Williams wrote:
> Can we make the webid that we put in the self-signed cert have the
> form
>
> http://foaf.com/peter.rdf#me#<hash> ?
Don't think so. That's an invalid URL I believe. (I may be wrong)
It is not good architecture to put meaning into URLs such that
protocols depend on those - which is not to say that they should not
be humanly readable. That ties URLs between sites much too closely
together, and I believe unnecessarily.
>
> Let's assume that the webid in the (self-signed) client cert's
> extended subject name (uri variety) has such a hash fragment - and
> that acts in addition to the fragment label (#me) that more
> typically denotes the asserted subject.
>
> Lets assume now that the value of the fragment is hash(foaffile).
>
> Could we make an SSL server's act of resolving the webid+fragment
> now validate the integrity of the referenced foaf data? ...much as
> one does with signed XRD today - when references in the signed info
> of an xml dsig are typically validated using hashes?
Again, I don't think that would be the right way to go about it. The
URL would have to change whenever you changed your file. Better to
just sign the document somehow that describes the resource canonically
referred to by the WebId. We have been thinking about that. But for
the moment have not explored signing the files, as that adds a level
extra complexity to the programming of the protocol. But it should be
possible to do that. We need to work out what advantages this would
procure. It may not be quite as much as hoped. It may be more.
Something to explore...
>
> To implement, one simply borrows the reference resolver/digester
> routines from the existing xml dsig API, surely?
>
>
> Of course, that objects in the foaf file denoted by "http://...#me"
> may also contain the assertion of the subject's openid "account" - a
> value such as http://openid.yahoo.com, perhaps.
yes, foaf has the foaf:openid relation that allows one to list the
openids a user has. use that to create a foaf+ssl OpenId proxy. Toby
Inkster wrote such a service which I described here:
see: http://blogs.sun.com/bblfish/entry/join_the_foaf_ssl_community
The nice thing about this OpenID IDP is that you don't have to enter
any attributes into it. You just leave them in your foaf file, and you
just get OpenId for free, and all the web sites just keep working.
That OpenId web service would need some work. It does not seem to work
with many services, but it proved the concept.
>
> Upon receiving the access request, now the SSL server might solicit
> an assertion from the OP, in order to locally link the webid (in one
> domain space) and openid (in another domain space).
>
> All we really need do to achieve this, surely, is put the users
> webid in the sreg.homepage store attribute.
You can do it more RESTfully by linking the openid page to the foaf,
and to the generic IDP.
>
> I'm never sure if folks desire to "harmonize" the various almost-
> mature identity efforts are real, or just lobbyist spin. If they are
> real, there is SO much we can do, when folks combine!
>
> Juts think about it. 3 outsider technologies (SSL client certs,
> FOAF, openid2) combining .. to define a version of https now fit for
> the semweb!!
Yep that would be really cool. I'll try to be at the Identity Workshop
in SF in November.
http://www.internetidentityworkshop.com/
Peter Williams
Perhaps its something like http://foo.com/#form$element$elementchild where everything following the # is a (compound) "tag". By definition the semantics of any such tag are "resource-defined"- which ASP.NET properly defined for its resources. Under the formal interpretation, the fragment is not (and this is counter intuitive) not part of the URI!!
I know I wrote user control for asp.net that spat this kind of markup out, server side. I just don't remember the syntax.
And I any case, a self-signed cert can have as many URIs as it likes, one per extended subject field: each a "synonym".
If one cannot post-fix the hash to "qualify" the webid, one can always add another URI... that is the webid's "synonym" - used much as in the XRD world of canonical-ids, to ensure one has an unambiguous reference point (for validation logics).
Anyways, think about the main point some more. The point was: that which openid2 removed from openid1 (rp-side name linking) CAN be put back - especially if the larger OPs refuse to support openid2-style vanity delegation.
-----Original Message-----
From: h...@bblfish.net [mailto:h...@bblfish.net] On Behalf Of Story Henry
Sent: Saturday, August 29, 2009 8:29 PM
To: Peter Williams
Cc: John Bradley; openid-...@lists.openid.net
Subject: Re: [OpenID] Windows Live ID OpenID CTP Status Update (August 2009)
On 30 Aug 2009, at 04:39, Peter Williams wrote:
> Can we make the webid that we put in the self-signed cert have the
> form
>
> http://foaf.com/peter.rdf#me#<hash> ?
Don't think so. That's an invalid URL I believe. (I may be wrong)
It is not good architecture to put meaning into URLs such that
protocols depend on those - which is not to say that they should not
be humanly readable. That ties URLs between sites much too closely
together, and I believe unnecessarily.
Story Henry
> What Im trying to recall is the markup used commonly for a control
> _tree_, in your typical ASP.NET rendering of a server side object set.
>
> Perhaps its something like http://foo.com/#form$element$elementchild
> where everything following the # is a (compound) "tag". By
> definition the semantics of any such tag are "resource-defined"-
> which ASP.NET properly defined for its resources. Under the formal
> interpretation, the fragment is not (and this is counter intuitive)
> not part of the URI!!
No, that is incorrect. A URL with a # fragment is a URL.
see:
http://labs.apache.org/webarch/uri/rfc/rfc3986.html#components
It is just that the meaning of that URL is specified by the
representation returned. see section 3.5 where it says:
[[
The fragment identifier component of a URI allows indirect
identification of a secondary resource by reference to a primary
resource and additional identifying information. The identified
secondary resource may be some portion or subset of the primary
resource, some view on representations of the primary resource, or
some other resource defined or described by those representations.
]]
So the following are two different URIs:
http://labs.apache.org/webarch/uri/rfc/rfc3986.html
http://labs.apache.org/webarch/uri/rfc/rfc3986.html#components
The first one refers to an html document, which is returned by a
successful HTTP GET request.
The second refers to a part of the first document, because the html of
the returned document contains the following html:
<h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5.</a> <a
name="fragment" href="#fragment">Fragment</a></h2>
and html specifies that id fragments refers to document parts.
Similarly
http://bblfish.net/people/henry/card
refers to an rdf document, more precisely a
foaf:PersonalProfileDocument, which is a subclass of documents. On the
other hand
http://bblfish.net/people/henry/card#me
refers to me, the person. This is specified by the representations
returned by the first URI.
> I know I wrote user control for asp.net that spat this kind of
> markup out, server side. I just don't remember the syntax.
>
> And I any case, a self-signed cert can have as many URIs as it
> likes, one per extended subject field: each a "synonym".
>
> If one cannot post-fix the hash to "qualify" the webid, one can
> always add another URI... that is the webid's "synonym" - used much
> as in the XRD world of canonical-ids, to ensure one has an
> unambiguous reference point (for validation logics).
Given that the beginning of your argument is mistaken, I am not sure I
follow you anymore here.
>
> Anyways, think about the main point some more. The point was: that
> which openid2 removed from openid1 (rp-side name linking) CAN be put
> back - especially if the larger OPs refuse to support openid2-style
> vanity delegation.
Sorry, I did not follow the story about vanity delegation.
Just as a matter of interest, in case it is relevant here, in foaf one
can indirectly identify a person via their OpenId.
$ cwm http://bblfish.net/people/henry/card --ntriples | grep -i '/
openid'
<http://bblfish.net/people/henry/card#me> <http://xmlns.com/foaf/0.1/openid
> <http://bblfish.net/> .
<http://bblfish.net/people/henry/card#me> <http://xmlns.com/foaf/0.1/openid
> <http://openid.sun.com/bblfish> .
This is because foaf:openid is defined as being a
owl:InverseFunctionalProperty. It only one thing can have that
relation to the same openid.
Can you tell me what you are trying to achieve without using too many
technical terms :-)
I'll try to explain how one can do that in the foaf world.
Henry
Peter Williams
"This fragment is not technically part of the URL. []"
I'll guess that the writers were simply trying to capture a less-than-formal notion of URLs from earlier generations of the web - that we also apply in openid.
I do now see we have philosophical different here, which may make make it hard for webids and openids to work well together (if we all get too tied to formal models, and starting citing abstract definitions).
We need to avoid frustration over such things. We probably all remember frustrating some poor guy over his desire for the openid spec to mandate and require http correctness, over applying 301s for persistent name changes, etc.
I'm not interested in engaging in world where, like semweb and XRI/XDI, webids are competing with openids for adoption (for this or that reason). Once Microsoft acts, I will have confidence that 100Million consumers can talk to our 1 millions realtor's portals, using openid for websso - aka problem solved. To go the next level for access control and trust management, with webids and foaf perhaps, some compromises are going to have to be fashioned.
-----Original Message-----
From: h...@bblfish.net [mailto:h...@bblfish.net] On Behalf Of Story Henry
Sent: Sunday, August 30, 2009 6:24 AM
To: Peter Williams
Story Henry
On 30 Aug 2009, at 17:28, Peter Williams wrote:
> I took my counsel on fragments from http://java.sun.com/javase/6/docs/api/java/net/URL.html?is-external=true
>
> "This fragment is not technically part of the URL. []"
That is sleight of hand in the Java documentation. That Java
documentation is not authoritative on the meaning of URLs. That's an
implementors point of view. :-)
> I'll guess that the writers were simply trying to capture a less-
> than-formal notion of URLs from earlier generations of the web -
> that we also apply in openid.
Yes, the Java URL class is designed to fetch a document, and to do
that it follows the HTTP protocol, which does indeed indicate that one
has to strip the #tag . So at that level it is correct. The Java URL
class is focused on that behavior. It does not take the bigger
architectural picture into consideration.
> I do now see we have philosophical different here, which may make
> make it hard for webids and openids to work well together (if we all
> get too tied to formal models, and starting citing abstract
> definitions).
We need to avoid coming to a conclusion too quickly here. The JavaDoc
does not exclude the IETF definition. It is just captures a part of it.
OpenIds and WebIds are very compatible. As I mentioned in my previous
email, foaf has the foaf:openid relation that relaties an agent to his
webid, in a way very similar in which it relates an foaf:Agent to a
email box with the foaf:mbox relation, or a foaf:Agent to a home page
with the foaf:homepage relation. Each of these relations is an
indirect identifier of an agent.
>
> We need to avoid frustration over such things. We probably all
> remember frustrating some poor guy over his desire for the openid
> spec to mandate and require http correctness, over applying 301s for
> persistent name changes, etc.
I am finding that people coming to the semantic web via foaf+ssl get
these concepts quite quickly. We have php developers who went from
knowing nothing about the semantic web to writing foaf+ssl servers.
The documentation and tools are now good enough that one can get going
quite easily.
> I'm not interested in engaging in world where, like semweb and XRI/
> XDI, webids are competing with openids for adoption (for this or
> that reason).
There is no competition. WebIds are direct identifiers, OpenIds are
indirect identifiers. They fulfil different roles, and are useful in
different ways. As I mentioned in my blog "Join the foaf+ssl community
and get OpenId for free" we have created a proxy OpenId service that
uses foaf+ssl authentication.
http://blogs.sun.com/bblfish/entry/join_the_foaf_ssl_community
> Once Microsoft acts, I will have confidence that 100Million
> consumers can talk to our 1 millions realtor's portals, using openid
> for websso - aka problem solved. To go the next level for access
> control and trust management, with webids and foaf perhaps, some
> compromises are going to have to be fashioned.
I don't think we need to compromise - and I don't mean that we have to
fight each other. :-) OpenIds and WebIds are compatible, so there is
no strain.
Hope this helps,
Peter Williams
Webid are direct identifiers
Openid are indirect identifiers.
And, from openid doctrine, the HXRI/XRI variety of openids are abstract identifiers.
The average vb programmer can get that set of distinctions. I don't, but it already sounds like something I could easily study to get over my ignorance.
So what is an unauthoritative ssl client cert, when asserted to the RP's SSL server? :-)
>From a security analysis POV, it's a worthless piece of nothing at all; except that - like formalized "ephemeral" certs in the SSL protocol - it has an interesting side-effect. It causes the RP's SSL server to have knowledge that the user possessed and used a private key, with its pretty canonical id (the public key bytes).
Now, we know from foaf+ssl, that if an SSL server [securely] resolves that incoming, canonical publickey id against a foaf file at the (direct) webid hinted at in the client cert blog, the fragment in the webid can properly identity which objects in the triple set one is after (for further processing by the layer 7 stack entity contributing to handling the https protocol). With a bit of triple store processing, even Peter can obtain the indirect openid (of which one abstract variant is the HXRI/XRI), and now talk to an OP to verify identifies (of all the sorts).
Now that's all well and good. And, I know your focus is access control thereafter, using foaf and linked networks of foaf files to ultimataly guard access to the resource identified in the https URL that started the whole sequence.
But, for me, the benefit is closer to home- coming down to making websso adoptable. I've got OPs trying to induce me to rely on THEIR names for the public - who do want to talk to my customers portal sites. But, this produces a LEVEL of dependency Im uncomfortable with. The security architect in me HAS to prepare for a breakdown in the relationship of a particular member of the public with Google OP (say). And that breakdown needs to have NO impact on the public's ongoing PRIVATE relationship with my customers. (And, probably they also don't want the likes of Google as OP knowing too much of their timing of or other history of interactions - since they and all other search engines will endeavor to crawl it, correlate it and publish it to the world, given half a chance - compromising the trust between realtor and client)
Now, openid 1 had it good (for me), as RPs performed and controlled the (cross domain) name mapping. That is, as RP I had ultimate control. I could even easily outsource that name mapping to an i-broker, managing the XRDs doing the name mappings. Today, with openid2, I no longer have this control (even in the latest, fancy signed XRDs from Google Apps for domains)
Im hoping that in tying direct, indirect and abstract identifiers back together SPECIFICALLY at the behest of _RPs_, foaf+ssl+openid can redress the balance of power - so RPs can once again control their own dependencies. I suspect this is critical to RPs choosing in general to adopt or not to adopt websso "for transactions beyond those that don't matter"
Story Henry
On 30 Aug 2009, at 19:32, Peter Williams wrote:
> So that was useful.
>
> Webid are direct identifiers
Yes.
> Openid are indirect identifiers.
the http:// ones yes.
They indirectly identify the user via the foaf:openid relation.
A|--------8<-----------------------8<------------------
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix : <http://bblfish.net/people/henry/card#> .
:me foaf:openid <http://bblfish.net/> .
----------->8----------------------->8------------------
Imagine an arrow pointing from me to that web page. The foaf:openid
relation is defined as being inverse functional, ie the inverse of
that relation, let's call it xxx:isOpenidOf relates the web page to me
is functional
B|---------8<-----------------------8<-------------------
<http://bblfish.net> xxx:isOpenidOf :me .
----------->8----------------------->8-------------------
so now imagine an arrow from that web page to me. I can have a number
of different names.
Indeed another URL for me is
C|---------8<-----------------------8<-------------------
@prefix sun: <http://sixiron.sfbay.sun.com:8080/FoafServer/services/people/155492#
> .
sun:HS a foaf:Person;
foaf:openid <http://bblfish.net> .
----------->8----------------------->8-------------------
from A and C an inferencing engine can deduce that
sun:HS = :me .
ie those two names refer to the same thing.
> And, from openid doctrine, the HXRI/XRI variety of openids are
> abstract identifiers.
HXRIs are I think direct identifiers too. The protocol and the URI is
not nearly as well established as http urls, so I have not spent a lot
of time looking at them. But from what I understood they should be
direct identifiers. =bblfish should identify me.
But that's ok. Because the foaf:openid relation is the one that is
inverse functional. So HXRIs will have an inverse functional
foaf:openid relation to the thing they identify, namely to themselves.
Ie it should be possible to write
=bblfish foaf:openid =bblfish .
> The average vb programmer can get that set of distinctions. I don't,
> but it already sounds like something I could easily study to get
> over my ignorance.
A very good introductory book is "Semantic Web for the Working
Ontologist". It's a bit of a mouthful, but it starts simple and easy
and progresses without ever bothering about rdf/xml.
http://blogs.sun.com/bblfish/entry/semantic_web_for_the_working
> So what is an unauthoritative ssl client cert, when asserted to the
> RP's SSL server? :-)
I suppose by "unauthoritative" you mean a client cert that is self
signed, or where we don't care about the signature.
A certificate is a document relating an identity to a public key. The
semantics of one of my certs would be given by:
D|--------8<-----------------------8<------------------
@prefix cert: <http://www.w3.org/ns/auth/cert#> .
@prefix rsa: <http://www.w3.org/ns/auth/rsa#> .
<> a foaf:Document;
foaf:primaryTopic :me .
:me a foaf:Agent;
foaf:name "Henry Story".
[] a rsa:RSAPublicKey;
cert:identity :me;
rsa:public_exponent [ cert:decimal "65537"] ;
rsa:modulus [ cert:hex
"862d6e0b8c3252a79d6eb82966f14e495c839ec2d57983ec39bfac79f8a99f887a
3ca559cfee438e90f73da143cefc0a849509d8d91e7093a94c1a39863a5bed78a0f0234a372f12dce0a9535b14d92d56827b3791352b5817681ad7949aa7831911d51827a57e46bad9190d73a69ce56ada74a59ddc0df2a7a31247bbd67445
"] .
----------->8----------------------->8-------------------
In foaf+ssl we use the alternativate name url to name the subject of
the certificate. If Distinguished Names were URIs we could use those
too.
So a certificate is not a URI. It is a document sent to the server. A
statement of identity. The rsa:RSAPublicKey node is not named - it
does not have a URL. ( hence the [] ) It is indirectly identified by
the pair of properties rsa:public_exponent and rsa:modulus which
relate public keys to numbers.
>> From a security analysis POV, it's a worthless piece of nothing at
>> all; except that - like formalized "ephemeral" certs in the SSL
>> protocol - it has an interesting side-effect. It causes the RP's
>> SSL server to have knowledge that the user possessed and used a
>> private key, with its pretty canonical id (the public key bytes).
>
> Now, we know from foaf+ssl, that if an SSL server [securely]
> resolves that incoming, canonical publickey id against a foaf file
> at the (direct) webid hinted at in the client cert blog, the
> fragment in the webid can properly identity which objects in the
> triple set one is after (for further processing by the layer 7 stack
> entity contributing to handling the https protocol). With a bit of
> triple store processing, even Peter can obtain the indirect openid
> (of which one abstract variant is the HXRI/XRI), and now talk to an
> OP to verify identifies (of all the sorts).
yes, you can use the openid relation in the foaf file, and do
something with that, such as verify identities. That is what the foaf
+ssl OpenId provider I mentioned before does.
http://blogs.sun.com/bblfish/entry/join_the_foaf_ssl_community
When the user logs into such an OpenId provider using foaf+ssl, the OP
having fetched the foaf file to verify identity, find the openid in
that graph, then gets the openid page and verifies that it points to
the foaf file as well as to the OP.
> Now that's all well and good. And, I know your focus is access
> control thereafter, using foaf and linked networks of foaf files to
> ultimataly guard access to the resource identified in the https URL
> that started the whole sequence.
>
> But, for me, the benefit is closer to home- coming down to making
> websso adoptable. I've got OPs trying to induce me to rely on THEIR
> names for the public - who do want to talk to my customers portal
> sites. But, this produces a LEVEL of dependency Im uncomfortable
> with. The security architect in me HAS to prepare for a breakdown in
> the relationship of a particular member of the public with Google OP
> (say). And that breakdown needs to have NO impact on the public's
> ongoing PRIVATE relationship with my customers. (And, probably they
> also don't want the likes of Google as OP knowing too much of their
> timing of or other history of interactions - since they and all
> other search engines will endeavor to crawl it, correlate it and
> publish it to the world, given half a chance - compromising the
> trust between realtor and client)
yes that makes a lot of sense.
>
> Now, openid 1 had it good (for me), as RPs performed and controlled
> the (cross domain) name mapping. That is, as RP I had ultimate
> control. I could even easily outsource that name mapping to an i-
> broker, managing the XRDs doing the name mappings. Today, with
> openid2, I no longer have this control (even in the latest, fancy
> signed XRDs from Google Apps for domains)
Oh, I see.
hmm. In OpenId 1 I thought that you had to use one of the Identity
Provider linked to from the openid page. I thought OpenId 1 did not
work with XRDs . How did the brokering work? Just a man in the middle
you trusted I suppose who could cover the identity of the real service
asking for authentication, I presume.
> Im hoping that in tying direct, indirect and abstract identifiers
> back together SPECIFICALLY at the behest of _RPs_, foaf+ssl+openid
> can redress the balance of power - so RPs can once again control
> their own dependencies. I suspect this is critical to RPs choosing
> in general to adopt or not to adopt websso "for transactions beyond
> those that don't matter"
Could well be.
foaf+ssl could by itself go even further. There are only three things
that need to be running for a foaf+ssl identification service to work.
1. The client machine that makes the connection
2. The server (RP) it is trying to connect to
3. the server serving the foaf file
Since The server serving the foaf file, can be on the same machine as
the client, then there are only two machines that need to be
functioning and alive: the client machine and the RP.
Perhaps that opens yet further possibilities.
Peter Williams
http://blogs.sun.com/bblfish/entry/join_the_foaf_ssl_community
When the user logs into such an OpenId provider using foaf+ssl, the OP
having fetched the foaf file to verify identity, find the openid in
that graph, then gets the openid page and verifies that it points to
the foaf file as well as to the OP.
Now that’s cute, because the second half is really only a minor variation of what OPs and RPs do today (using HTML metatags and XRD.SEP.localids for cross-domain name mapping). It goes a bit further in the first half, as it also address user auth (by providing a basis for accepting the SSL layers of assertion of uncertified public key as one that actually binds to a webid, that implies an openid, which an OP may now release to the RP as a claimed identifier). (*)
But also note how different it was in application to my conception. I had the foaf+ssl talking to the RP rather than the OP (where the RP which would do all the various mappings, resolvings, and verifying). I shifted the control point (back the way it was in the openid1 world), turning the OP into just one of several transitory intermediaries on the message relay path that separates me the RP from you the user.
Now the nice thing is, that I think both controls models work; and neither excludes the other. Either RP or OP can be applying this sort of thing, or BOTH can. Thus, we address the balance of power issue, addressing the issue of dependency becomes a barrier to adoption. One gets around the confidence problem of dependency, because as an RP one now has built in resilience to failure, and the expectation that of course the RP can ALSO challenge the user directly (using its own run of foaf+ssl).
Peter.
(*) rather than have a third-party sign the foaf file, I’d still like the ssl layer (at RP) to be verifing the digest of the foaf file referenced by the webid (where the hash is in some of other field of the client cert, tied to that foaf file). In this way, the whole system is one of essentially one of an ssl-based, self-assertion of an authenticated foaf file to the RP (making things akin to a self-asserted infocard).
Peter Williams
-----Original Message-----
From: h...@bblfish.net [mailto:h...@bblfish.net] On Behalf Of Story Henry
Sent: Sunday, August 30, 2009 9:50 AM
To: Peter Williams
Cc: openid-...@lists.openid.net; John Bradley
Subject: Re: [OpenID] Windows Live ID OpenID CTP Status Update (August 2009)
On 30 Aug 2009, at 17:28, Peter Williams wrote:
> I took my counsel on fragments from http://java.sun.com/javase/6/docs/api/java/net/URL.html?is-external=true
>
> "This fragment is not technically part of the URL. []"
That is sleight of hand in the Java documentation. That Java
documentation is not authoritative on the meaning of URLs. That's an
implementors point of view. :-)
Not that it’s too relevant since we got to the more important architectural points ore relevant to openid, but the java doc is entirely supported by the (older) RFC on URLs that it references, which says the same thing.
The ref’s syntax is necessarily resource-defined, and the UA should parse it according to the dictates of the media type sent along with the retrieved file. If the foaf stream at a webid s delivered under a mime type with suitable qualifier (e.g. text/foaf+rdf;webid=true ) the UA (which of course is the OP’s or RP’s SSL server) can know to parse out the fragment ref of the non absolute URI part of the webid, thereby determining from the cert a hash component. From existing knowhow I have, I know its trivial to take the apache xml dsig resolver for digesting http references, subclass the resolver to de-reference the webid, and ensure its digest is equal not to the digest values in the xml dsig block now but to the hash component on the webid (after parsing the fragment, to suit the profile)!
Hardly very semweb, I agree; but then semweb reasoning doesn’t address ssl. And, here we are using SSL not only as a transport but as a signaling mechanism for the public key id.
To the lexer, a fragment’s tag (ref/reference) is also apparently a *uric - which charset apparently includes hash (not that this choice of separator is exactly critical!)
I believe I saw that your project allows source programmers to take an SSL server implementation, add it to tomcat listener/server, and then “extend SSL”. If this is true, I’ll have a go – since I have a certain familiarity with the insides of the SSL protocol. I think this is all within my prototyping capabilities. I completed adding signed XRD chains to the XRI server last month, which got me over 10 years laziness/avoidance-of anything to do with Java enterprise systems. Java on the server side is seeming all rather cute (now someone _else_ has made it mature).
Story Henry
On 31 Aug 2009, at 03:30, Peter Williams wrote:
>> From: h...@bblfish.net [mailto:h...@bblfish.net] On Behalf Of Story
>> Henry
>> Sent: Sunday, August 30, 2009 9:50 AM
>> To: Peter Williams
>> Cc: openid-...@lists.openid.net; John Bradley
>> Subject: Re: [OpenID] Windows Live ID OpenID CTP Status Update
>> (August 2009)
>> On 30 Aug 2009, at 17:28, Peter Williams wrote:
>>
>>> I took my counsel on fragments from ?> http://java.sun.com/javase/6/docs/api/java/net/URL.html?is-external=true
>>>
>>> "This fragment is not technically part of the URL. []"
>>
>> That is sleight of hand in the Java documentation. That Java
>> documentation is not authoritative on the meaning of URLs. That's an
>> implementors point of view. :-)
>
> Not that it's too relevant since we got to the more important
> architectural points ore relevant to openid, but the java doc is
> entirely supported by the (older) RFC on URLs that it references,
> which says the same thing.
>
>
> The ref's syntax is necessarily resource-defined, and the UA should
> parse it according to the dictates of the media type sent along with
> the retrieved file. If the foaf stream at a webid s delivered under
> a mime type with suitable qualifier (e.g. text/foaf+rdf;webid=true )
> the UA (which of course is the OP's or RP's SSL server) can know to
> parse out the fragment ref of the non absolute URI part of the
> webid, thereby determining from the cert a hash component.
yes, the mime type of the document returned determines the
interpretation of the document.
Note that the mime type for rdf/xml is
application/rdf+xml
There is no need to add ";webid=true", as rdf/xml and other rdf/
formats specify this process clearly. I mean the process of how one
takes a document with relative URIs to produce a graph with absolute
URIs.
There are rdf serialisations which don't require such a process. The
NTriples format for example encodes everything as an absolute URL. See:
http://www.w3.org/2001/sw/RDFCore/ntriples/
You can translate any rdf document in NTriples using the python cwm
script.
$ cwm http://bblfish.net/people/henry/card --ntriples
> From existing knowhow I have, I know its trivial to take the apache
> xml dsig resolver for digesting http references, subclass the
> resolver to de-reference the webid, and ensure its digest is equal
> not to the digest values in the xml dsig block now but to the hash
> component on the webid (after parsing the fragment, to suit the
> profile)!
Currently in foaf+ssl we don't sign the foaf file. For security, to
avoid man in the middle attacks, it should be served via https.
I am not sure what the correct procedure for signing xml files would
be. I did not look into that yet, as it adds one more layer of
complexity to the framework, and we are trying to drive adoption, so
we can test the concepts in more detail.
>
> Hardly very semweb, I agree; but then semweb reasoning doesn't
> address ssl. And, here we are using SSL not only as a transport but
> as a signaling mechanism for the public key id.
SSL as it is used for fetching the foaf file, is used here only as a
secure transport mechanism. It is transparent to the semweb layer.
> To the lexer, a fragment's tag (ref/reference) is also apparently a
> *uric - which charset apparently includes hash (not that this choice
> of separator is exactly critical!)
>
>
> I believe I saw that your project allows source programmers to take
> an SSL server implementation, add it to tomcat listener/server, and
> then "extend SSL".
The ssl implementation that needs to be hacked is the Relying Party's
one. The server serving the foaf file is a bog standard one, and does
not need to be patched.
The Relying Party's ssl server needs to be a lot more flexible than
most ssl stacks are when it asks for the client certificate. In foaf
+ssl we do not need to tie the client certificate to a well known
Certificate Authority (CA). This is exactly what makes foaf+ssl so
attractive.
The default implementation of ssl in Java, tries to verify the CA.
If it does not know the CA, then the connection attempt is deemed have
failed. This is what needs to be patched. Details on how to do this in
Java are here:
http://blogs.sun.com/bblfish/entry/how_to_setup_tomcat_as
It is quite easy to get the same done in Apache. There is a way to set
up apache so that it can pass the client cert onto the CGI application
to continue the verification procedure.
> If this is true, I'll have a go - since I have a certain familiarity
> with the insides of the SSL protocol. I think this is all within my
> prototyping capabilities. I completed adding signed XRD chains to
> the XRI server last month, which got me over 10 years laziness/
> avoidance-of anything to do with Java enterprise systems. Java on
> the server side is seeming all rather cute (now someone _else_ has
> made it mature).
I think you should find this even easier than you thought. If you just
want to use Apache check out the documentation on http://foaf.me,
which uses php. We have implementations in perl and python too.
Henry
Peter Williams
If the handoff from ssl layer 4 (ssl record layer stuff) to app layer 7 (which does cert stuff) to CGI/servlet interface is now open in some of the major containers, there is lots that can be done to insert non-DNS based trust models at this interception point: for openid implementations, too. This is worth studying, for lots of reasons; since its "deployable".
Story Henry
> We are probably too far distant from openid to use this list
> further. Is there a vibrant community of participants on another,
> better suited? The more diverse the opinion set, the better,
> usually. Good standards are a mix of political compromises and
> technology.
Well there is the foaf-protocols mailing list
http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
There may be other lists I should introduce this too. But I think in
helps if I first give a real presentation to a group of people live.
It helps get people's intuitions lined up. Perhaps you have ideas of
conferences I should present too that would make a big difference. I
will be going to the Identity Interest group in November to present.
> If the handoff from ssl layer 4 (ssl record layer stuff) to app
> layer 7 (which does cert stuff) to CGI/servlet interface is now
> open in some of the major containers, there is lots that can be done
> to insert non-DNS based trust models at this interception point: for
> openid implementations, too. This is worth studying, for lots of
> reasons; since its "deployable".
yes. And we have working examples too. We just need more of them and
more useful ones to get this going.
Henry
Peter Williams
You have to be very personable to get a hearing for a pitch; but I don't think you have any problem there!
Bring some political ammunition tho, if you come. To get some bit of technology adopted, youll have to scratch someone's back so they get what they want. What *I* want is harmony between OASIS and W3C over XRI/XDI/XRD, so we can ALL leave dns behind us. Do some bridging there, and I bet trustworthiness will go way off the scale.
-----Original Message-----
From: h...@bblfish.net [mailto:h...@bblfish.net] On Behalf Of Story Henry
Sent: Monday, August 31, 2009 2:57 AM
To: Peter Williams
Cc: openid-...@lists.openid.net
Subject: Re: [OpenID] Windows Live ID OpenID CTP Status Update (August 2009)
John Bradley
Peter Williams
From: John Bradley
[mailto:john.b...@wingaa.com]
Sent: Sunday, August 30, 2009 2:06 PM
To: Peter Williams
Cc: Story Henry; Jo...@osuosl.org; openid-...@lists.openid.net
Subject: Re: [OpenID] Windows Live ID OpenID CTP Status Update (August
2009)
One thing we do lack is a consensus on what openID is other than a redirect based protocol with a symmetric shared secret between the OP and RP per the openID 2.0 spec.
So a good first question to tackle is should asymmetric cryptography RSA/ECDSA be a part of the core spec.
If the answer continues to be no then it takes a bunch of options off the table.
I think the answer for extensions like CX and secure discovery may well be different than for the core spec.
I am interested in what people thing openID is or should be going forward.
That which folks could not do to enhance SSL itself for websso (because of the way IETF works, and who runs/influences the contributors/editors of that forum), I see openid as having done through market forces. Openid is to me an enhanced session manager for ssl sessionids, with the added value of discovery and authorization controls – that allow multiple “SSL connections” to be proxied UNDER policy control (rather than ad-hoc http proxy/connects that just fashioned a MITM space).
Now, the deployed SSL would need to be unhooked from the https-level de-facto policy of tying trust to the DNS – which is currently partially governing end-end connection policie (under ideas from 15 years ago (that have not moved forward one iota)).
So, just as facebook have treated openid as a hidden protocol under a UX flow (using only a slice of the protocol furthermore to do machine-machine signalling), so one can continue the trend, working towards openid supporting machine-machine authentication for web services, etc. This obviously leaves behind the restriction of openid as being ONLY a foreground protocol, addressing UCI, privacy, control and all the other in-your face issues.
So, the more the SSl handshake/event-handlers and openid state machines merge, the better. Then, a market will emerge for hardware that can do NAT/load-balancer offloading of https/openid today, just as the same switches now do multi-gigabit/s ssl offloading and proxing.
If the same trends were also to be incorporating the yet more powerful foaf+ssl ideas (which are admittedly 3-4 behind the adoption curve of openid2), those switches would able to set to do what many used to think of secure XML routers doing (the so-called AOS devices, from the likes of HP and Intel). But rather than do it with messages, one would be doing it with sessions – which we know has proven itself a scalable winner for fast hardware. But those sessions would now have inferecing based routing – which takes us above and beyond the dynamic routing regimes of the internet backbones and into true virtual routing.
If one goes with this trend analysis, yes public key is part of openid, but through an ever tighter association with the SSL handshake and event handlers, not because openid does an alternative( relatively crappy) job of repeating what SSL does so well.
There were attempts to add certain NR-features to openid, that unfortunately got caught up in patent issues. But, many folks see a need for SSL to ALSO allow the servers behind the loadbancer offloaders to retain a measured of crypto-level relationship to the client. Here, again, I suspect openid could be adding that something back to SSL (and be doing something useful without getting into the patented areas).
If one accepts any of the above, then yes CX and secure discovery are simply using this “new https” as a bearer, and openid “extensions” are to such an ssl+openid-bearer what https apps are to the SSL record layer today – consumers of generic session-oriented security services. But, the https layer has moved on a generation.
John Bradley
Dick Hardt
On 2009-08-30, at 2:06 PM, John Bradley wrote:
> So a good first question to tackle is should asymmetric cryptography
> RSA/ECDSA be a part of the core spec.
+1
John Panzer
identify themselves)
i know the arguments against this but the benefits outweigh the drawbacks.P
On Saturday, August 29, 2009, Allen Tom <at...@yahoo-inc.com> wrote:
> How about if we ditch the OP buttons and just display this:
>
> Enter your email address or Profile URL: [...................]
>
> Allen
>
>
> John Bradley wrote:
>
>
>
> A better UI is needed however.
>
>
>
Jonathan Coffman
be, coupled with some tiny little NASCAR action underneath? (I'm
thinking a visual similar to social bookmarking chiclets)
