[foaf-protocols] voting for Mozilla bug

[Story Henry]

On 9 Feb 2010, at 18:33, Peter Williams wrote:

> It one of those sites that wants one to make another account (rather than  rely on websso). I avoided it. It's making the problem worse by maintaining that posture.

One can't change the world in one day...

> It conflates client certs (and ui) with logon state at sites.

Ok so I suppose you are speaking of the proposal on the bug page, which is complex but I suppose is similar to what I referenced here - the mozilla Weave project:
  http://blogs.sun.com/bblfish/entry/identity_in_the_browser_firefox

> Client certs are about transport security, not session state.  Yes client certs authenticated by ssl (with optional validation logics such as https or ftps or ldaps or foaf-ssl) are tokens that can be exchanged for "logon" token issues by sites. The latter token may expire in a week (like a yahoo logon token), 5 days after the cert token expired (depending on validation logic design).

If I understand you correctly you are referring to the possibility that the web site would set a cookie when it received the certificate. It could then later continue to identify the client using only that cookie over a server side encrypted https session....

But would that be as secure? The second cookie use could be sent by someone else using the browser... (imagine the browser requires a password to access the keychain) If so it seems to me the identification using client side certificates is really tied to the sll channel using that certificate. Anything else is much weaker identification: something more like, from the point of view of the server: the person on the other end of the connection is using the same browser as the previously identified person.

> Cert selection is tied to ssl ciphersuite negotiation. Different certs may in play on one site, as controlled by the page javacript (and it's socket channels that bypass browsers) rather than the browser.

Ok, but I don't think that means the browser cannot present graphically information of under what identity the retrieved resources were sent. Why could browsers tell one what web site one connect to but not what identity one used in connecting?

Perhaps it is more complex. So let's consider in order of increasing complexity:

1. There is only one resource composing the page - 1 html document for example - and it was fetched from a server asking for one client certificate. 

  Would it not be ok to show the user in the URL bar iconically whichclient certificate he used? (as shown in the pictures on http://blogs.sun.com/bblfish/entry/identity_in_the_browser_firefox )

2. There are a number of resources from the same server using the same connection that had requested the client certificate. Same as above then.

3. All resources are fetched from the same server but with different security levels, but alway s using the same client cert. Perhaps the button in the browser instead of being of being deep green could be a slightly lighter green then? 

3. More problematic is what UI one should show when the document shown to the user comes from a number of different connections, some of them from different servers (perhaps even using different identities?) Perhaps some icon showing the user a list of client identities would help. Perhaps by mousing over this the user could get some idea of which resources came from where....

I am not saying it is easy, but I don't see that it is not impossible to at least do something a lot better than what is now: namely to see what identifying information the user presented to receive the page that is displayed in the browser.

Or can you put forward a very simple use case that would occur in 40% of the case or at least some very large number of useful ones, which shows this whole enterprise to be nonsensical?


> 
> 
> On Feb 8, 2010, at 8:17 AM, Story Henry <henry.story at bblfish.net> wrote:
> 
>> Hi All,
>> 
>> We have over 100 people on this list. Here is a little work for those lurking on the sidelines,  (and everyone else as well) that could help us a lot. Every so often we will take a browser bug, and ask everyone here to participate in voting for it, to wake the browser guys up, who seem to be sleeping at the wheel.
>> 
>> Mozilla's main bug seems to be the following:
>> 
>>  https://bugzilla.mozilla.org/show_bug.cgi?id=396441
>> 
>> The minimal thing to do is just go, get an account there, and vote for that bug.
>> 
>> You could also make a special comment if you feel particularly strongly about something.
>> 
>> eg:
>> 
>> Currently one does not know what certificate one is using when connected to a specific web site, or if indeed one was refused because the browser refused to send a certificate. This can be easily fixed using a UserInterface as the Weave people are putting together.
>> 
>>  http://blogs.sun.com/bblfish/entry/identity_in_the_browser_firefox
>> 
>> If people know people at Mozilla, please get in contact with them, and ask them what is happening, and why this would be really cool.
>> 
>>   Henry
>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols at lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>>