W3C home > Mailing lists > Public > public-identity@w3.org > March 2012

Re: Beyond HTTP Authentication: OAuth, OpenID, and BrowserID: Meeting on March 29th at IETF83

From: Anders Rundgren <anders.rundgren@telia.com>
Date: Tue, 20 Mar 2012 20:48:09 +0100
Message-ID: <4F68DEF9.50608@telia.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
CC: "public-identity@w3.org" <public-identity@w3.org>, Harry Halpin <hhalpin@w3.org>
On 2012-03-20 13:42, Hannes Tschofenig wrote:
> Hi Anders,

Hi Hannes,
This is not particularly simple to discuss over e-mail but I'll
give it a shot.


> the issue is that most SDOs care about focusing their work on
> interoperability aspects rather than on how the actual stuff is implemented.

Since key-enrollment currently is all-over-the-map one wonder how
to interpret the current situation.  SDOs doesn't really cut it?
Vendors firmly believe they need to be "different"?


> It makes sense to put requirements for the secure storage in a future
> version of the JavaScript CryptoAPI document but it has to be kept
> at a fairly high level to be useful.

As you surely know end-to-end security solutions like TLS presumes a
one-to-one correspondence between the client and server.  If the client
actually is a key-container this means that the server must talk the
key-container's native lingo if end-to-end security enrollment is to be
achieved.

My solution FWIW to this problem is "standardizing" the key-container.
Note: only the API + visible architecture is standardized, there
is no HW mandate although I'm *trying* to get inside of CPUs.


What is your solution to this?  Skip end-to-end security enrollment?
Framework standards that can adopt any kind of key-store standard?


> I don't believe it makes sense to touch the hardware or operating system
> level aspects in any of the document we are talking about here.

Google's Wallet is an example of the opposite notion.  This path may not
be W3C's cup of tea but that is what it may have to compete with.

If we are only talking about DOMCrypt with domain-bound keys you are
of course perfectly right; I'm rather talking X.509, On-line banking,
and President Obama's NSTIC.

Cheers,
Anders


> 
> Ciao
> Hannes
> 
> 
> On Mar 20, 2012, at 12:15 PM, Anders Rundgren wrote:
> 
>> On 2012-03-20 08:53, Hannes Tschofenig wrote:
>>> Hi Anders, 
>>>
>>> I believe that these topics will be discussed and investigated in the 
>>> W3C Web Cryptography Working Group.  Wouldn't you think so?
>>
>> Hi Hannes,
>> I guess that depends on what you define as the actual topic, right?
>>
>> From my watchtower it is the fact that there are only three vendors
>> of mobile operating systems and these give you quite limited access
>> to core parts through "Apps" which means that if interoperability is
>> to be achieved standard are necessary.
>>
>> This differs greatly from the previous situation where anybody could
>> deploy their proprietary DLLs and EXEs and thus be "Windows compatible".
>>
>> There is to my knowledge no SDO who have taken on secure key storage and
>> provisioning.  In TCG (which I'm a member of), secure key storage is on
>> the menu but the provisioning has been left to vendors to cater for.
>>
>> I doubt that any of the vendors in question are prepared discussing this
>> topic in a public forum.  Are you actually even allowed to do that?
>>
>> The Google wallet (as an example...), is in spite of all the hype not
>> publicly described.  One of the reasons is that the NXP-chip is NDA-
>> protected.  Since this is the case with most security hardware, I was
>> essentially forced switching to Open Security Hardware for my project.
>>
>> Cheers,
>> Anders
>>
>>>
>>> Ciao
>>> Hannes
>>>
>>> On Mar 20, 2012, at 7:22 AM, Anders Rundgren wrote:
>>>
>>>> On 2012-03-19 23:03, Harry Halpin wrote:
>>>>
>>>> I won't make it to IETF 83.   Here comes a short presentation
>>>> on how I envision that keys will be dealt with in the future:
>>>>
>>>> http://openkeystore.googlecode.com/svn/trunk/resources/docs/tee-se-combo.pdf
>>>>
>>>> There is a Reference Implementation as well:
>>>> http://code.google.com/p/openkeystore/source/browse/trunk/library/src/org/webpki/sks/twolayer/se/SEReferenceImplementation.java
>>>> http://code.google.com/p/openkeystore/source/browse/trunk/library/src/org/webpki/sks/twolayer/tee/TEEReferenceImplementation.java
>>>>
>>>> thanx,
>>>> Anders Rundgren
>>>> http://webpki.org/auth-token-4-the-cloud.html
>>>>
>>>>> Not sure how many people are making it to IETF83, but W3C is hosting an 
>>>>> onsite meeting on Thursday to discuss OAuth, BrowserID, OpenID, and the 
>>>>> upcoming W3C Web Cryptography Working Group. Everyone is invited!
>>>>>
>>>>> ==Beyond HTTP Authentication: OAuth, OpenID, and BrowserID==
>>>>>
>>>>> =Time and Location=
>>>>>
>>>>> Thursday lunchtime (1130 to 1300) in room 252A just between the SCIM BoF 
>>>>> and OAuth WG as part of IETF83 in Paris.
>>>>>
>>>>> = Problem Statement=
>>>>>
>>>>> While OAuth has solved the authorization problem, currently 
>>>>> authentication on the Web is still insecure as it has yet for the most 
>>>>> part failed to go beyond user-names and passwords. However, at this 
>>>>> point a number of new client-side capabilities, including the 
>>>>> possibility of W3C standardized Javascript cryptographic primitives, are 
>>>>> emerging and a number of specifications such as OpenID Connect, 
>>>>> BrowserID, and discussions over the future of HTTP Auth have shown that 
>>>>> there is interest in understanding better how client-side key material 
>>>>> can be used to enable a more secure Web authentication. However, there 
>>>>> has yet to be consensus on how client-side cryptography can enable 
>>>>> higher-security OAuth flows. The purpose of this side meeting is to look 
>>>>> at a more coherent picture of how technologies in the space of identity, 
>>>>> authentication, and authorization combine and interact and to help frame 
>>>>> future work in Web authentication.
>>>>>
>>>>> This informal meeting will present a number of proposed technical 
>>>>> proposals in brief, including relationships to other existing work (such 
>>>>> as RTCWeb and the upcoming W3C Web Cryptography Working Group), and to 
>>>>> help frame future work in the area.and then precede with open discussion.
>>>>>
>>>>> For any questions, please contact Harry Halpin (hhalpin@w3.org)
>>>>>
>>>>> =Schedule:=
>>>>>
>>>>> 11:30-11:45 Lightning presentations to "level-set" participants.
>>>>>
>>>>> Mike Jones (Microsoft) will present the latest work from JOSE and OpenID 
>>>>> Connect
>>>>> Eric Rescorla (Mozilla hat on) will present Mozilla Persona and 
>>>>> RTCWeb/WebRTC work
>>>>> Blaine Cook will present OAuth 2.0
>>>>> Harry Halpin (W3C) will present the upcoming W3C Web Cryptography API.
>>>>>
>>>>> 11:45-13:00 Open discussion on co-ordination between OAuth, HTTP Auth, 
>>>>> OpenID Connect, BrowserID, and W3C.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
> 
> 
> 
Received on Tuesday, 20 March 2012 19:48:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 20 March 2012 19:48:47 GMT