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

Discussion:

Harry Halpin

2012-03-19 22:03:50 UTC

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 (***@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.

Francisco Corella

2012-03-20 03:33:18 UTC

Permalink

Harry,

Are you still planning on organizing a workshop on the use of certificates for user authentication on the Web? You've said a couple of times that you wanted to have one this spring.

Francisco

________________________________
Sent: Monday, March 19, 2012 3:03 PM
Subject: Beyond HTTP Authentication: OAuth, OpenID, and BrowserID: Meeting on March 29th at IETF83
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.
=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.

Anders Rundgren

2012-03-20 05:22:43 UTC

Permalink

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

Post by Harry Halpin
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.
=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.

Hannes Tschofenig

2012-03-20 07:53:14 UTC

Permalink

Hi Anders,

I believe that these topics will be discussed and investigated in the W3C Web Cryptography Working Group.
Wouldn't you think so?

Ciao
Hannes

Post by Anders Rundgren
I won't make it to IETF 83. Here comes a short presentation
http://openkeystore.googlecode.com/svn/trunk/resources/docs/tee-se-combo.pdf
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

Anders Rundgren

2012-03-20 10:15:06 UTC

Permalink

Post by Hannes Tschofenig
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?

Post by Hannes Tschofenig
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

Post by Hannes Tschofenig
Ciao
Hannes

Mo McRoberts

2012-03-20 10:21:21 UTC

Permalink

Post by Anders Rundgren
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.

*Tangentially related*, I blogged a little bit about secure provisioning the other day:

http://nevali.net/post/19391532575/provisioning-keys-and-provenance

(if memory serves we've talked around this list in the past — so to be clear, I'm not claiming to have invented anything, just written it up)

As with everything, I'm sure there's a terribly good reason why somebody or other wouldn't want to implement such a thing.

M.
--
Mo McRoberts - Technical Lead - The Space,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Project Office: Room 7083, BBC Television Centre, London W12 7RJ

http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Anders Rundgren

2012-03-20 11:39:39 UTC

Permalink

Post by Mo McRoberts

http://nevali.net/post/19391532575/provisioning-keys-and-provenance

*Highly related* I would say.

Post by Mo McRoberts
(if memory serves we've talked around this list in the past — so to be clear, I'm not claiming to have invented anything, just written it up)
As with everything, I'm sure there's a terribly good reason why somebody or other wouldn't want to implement such a thing.

According to a US government official I met in Washington DC, there is a
reason why provisioning is not a part of the US PIV smart card standard
and that spells "hardware vendor". This has severely dwarfed the PIV
as a standard for other parties and in the end everybody lost.

I actually tried to purchase security hardware from a couple of vendors but
then I had to specify how many 10K (!) units I needed as well as signing NDAs.
I would also not be able to publish the code. Case closed, or as I found
out later: Open Security Hardware is nowadays a viable alternative.

Anyway, bridging the gap from crypto hardware to the browser is actually
not a simple task. Here is my take on the subject:
http://openkeystore.googlecode.com/svn/trunk/resources/docs/Efficient-Provisioning-of-Complex-Structures-Over-Unsecured-Channels.pdf

Anders

Post by Mo McRoberts
M.

Hannes Tschofenig

2012-03-20 12:42:21 UTC

Permalink

Hi Anders,

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

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.

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.

Ciao
Hannes

Post by Anders Rundgren

Post by Hannes Tschofenig
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

Post by Hannes Tschofenig
Ciao
Hannes

Anders Rundgren

2012-03-20 19:48:09 UTC

Permalink

Post by Hannes Tschofenig
Hi Anders,

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

Post by Hannes Tschofenig
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"?

Post by Hannes Tschofenig
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?

Post by Hannes Tschofenig
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

Post by Hannes Tschofenig
Ciao
Hannes

Post by Anders Rundgren

Post by Hannes Tschofenig
Hi Anders,
I believe that these topics will be discussed and investigated in the
W3C Web Cryptography Working Group. Wouldn't you think so?

Post by Hannes Tschofenig
Ciao
Hannes

Francisco Corella

2012-03-20 21:27:45 UTC

Permalink

Harry,

This thread shows that a workshop on user certificates would be useful. Are you still planning on having one this spring, or have you given up on that?

Thanks,

Francisco

Harry Halpin

2012-03-21 10:15:32 UTC

Permalink

Post by Francisco Corella
Harry,
This thread shows that a workshop on user certificates would be
useful. Are you still planning on having one this spring, or have you
given up on that?

We'll see. It depends on how the Web Crypto WG goes, some amount
(although not everything talked about on this mailing list) certificate
handling is in "secondary features" so I see no real reason for another
workshop at this point unless it seems another WG is necessary to do
that work.

Post by Francisco Corella
Thanks,
Francisco

Francisco Corella

2012-03-21 16:12:50 UTC

Permalink

Harry,

Post by Harry Halpin

Post by Francisco Corella
This thread shows that a workshop on user certificates would be
useful. Are you still planning on having one this spring, or have
you given up on that?

We'll see. It depends on how the Web Crypto WG goes, some amount
(although not everything talked about on this mailing list)
certificate handling is in "secondary features" so I see no real
reason for another workshop at this point unless it seems another WG
is necessary to do that work.

The Web Crypto WG is about a JavaScript API. Issuing and using
certificates should not require JavaScript. TLS client certificates
are not a JavaScript feature. The <keygen> element, a building block
for certificate issuance, is not a JavaScript feature. It is possible
today to issue a certificate automatically to at least one browser
(Firefox) without JavaScript, although not securely.

A workshop would help you decide whether a WG is needed; and it would
be useful to get the people interested in certificates in one room,
whether or not a WG follows.

Francisco

Henry Story

2012-03-21 16:25:51 UTC

Permalink

Btw. Certificates and a JS Crypto api should work very well together.

You would just get the best of both worlds. It is odd to try to make
syntactic distinctions between certificate formats and have JS APIs
be sensitive to those. To do so can only be a political decision, and
engineering based on that can only lead to laughable results.

Anyway I also happen to live close to Paris. If you want I could present WebID
quickly and show how these fit together. I argued for it here

http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid

but there are many aspects to it. A face to face can't harm.

Henry

Post by Francisco Corella
Harry,

Post by Harry Halpin

Post by Francisco Corella
This thread shows that a workshop on user certificates would be
useful. Are you still planning on having one this spring, or have
you given up on that?

We'll see. It depends on how the Web Crypto WG goes, some amount
(although not everything talked about on this mailing list)
certificate handling is in "secondary features" so I see no real
reason for another workshop at this point unless it seems another WG
is necessary to do that work.

The Web Crypto WG is about a JavaScript API. Issuing and using
certificates should not require JavaScript. TLS client certificates
are not a JavaScript feature. The <keygen> element, a building block
for certificate issuance, is not a JavaScript feature. It is possible
today to issue a certificate automatically to at least one browser
(Firefox) without JavaScript, although not securely.
A workshop would help you decide whether a WG is needed; and it would
be useful to get the people interested in certificates in one room,
whether or not a WG follows.
Francisco

Social Web Architect
http://bblfish.net/

Anders Rundgren

2012-03-21 20:04:08 UTC

Permalink

Post by Henry Story
Btw. Certificates and a JS Crypto api should work very well together.
You would just get the best of both worlds. It is odd to try to make
syntactic distinctions between certificate formats and have JS APIs
be sensitive to those. To do so can only be a political decision, and
engineering based on that can only lead to laughable results.

If you are referring to DOMCrypt I don't agree because DOMCrypt [AFAIK] builds
on domain-bound keys which doesn't translate to certificates unless these
also are domain-bound. Domain-bound certificates would be a crummy concept
since the public key should be known by the RP in most DOMCrypt scenarios.

Mozilla's crypto.signText () is IMO a better JS+X.509 fit than DOMCrypt.
They build on quite different principles.

Anders

Post by Henry Story
Anyway I also happen to live close to Paris. If you want I could present WebID
quickly and show how these fit together. I argued for it here
http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid
but there are many aspects to it. A face to face can't harm.
Henry

Post by Francisco Corella
Harry,

Post by Harry Halpin

Post by Francisco Corella
This thread shows that a workshop on user certificates would be
useful. Are you still planning on having one this spring, or have
you given up on that?

We'll see. It depends on how the Web Crypto WG goes, some amount
(although not everything talked about on this mailing list)
certificate handling is in "secondary features" so I see no real
reason for another workshop at this point unless it seems another WG
is necessary to do that work.

The Web Crypto WG is about a JavaScript API. Issuing and using
certificates should not require JavaScript. TLS client certificates
are not a JavaScript feature. The <keygen> element, a building block
for certificate issuance, is not a JavaScript feature. It is possible
today to issue a certificate automatically to at least one browser
(Firefox) without JavaScript, although not securely.
A workshop would help you decide whether a WG is needed; and it would
be useful to get the people interested in certificates in one room,
whether or not a WG follows.
Francisco

Social Web Architect
http://bblfish.net/

Jarred Nicholls

2012-03-21 20:17:55 UTC

Permalink

On Wed, Mar 21, 2012 at 4:04 PM, Anders Rundgren

Post by Anders Rundgren

If you are referring to DOMCrypt I don't agree because DOMCrypt [AFAIK] builds
on domain-bound keys which doesn't translate to certificates unless these
also are domain-bound. Domain-bound certificates would be a crummy concept
since the public key should be known by the RP in most DOMCrypt scenarios.
Mozilla's crypto.signText () is IMO a better JS+X.509 fit than DOMCrypt.
They build on quite different principles.

DOMCrypt can be whatever we want it to be. Nothing locks its future
expansions into being solely domain-based.

Post by Anders Rundgren
Anders

Post by Henry Story
Anyway I also happen to live close to Paris. If you want I could present

WebID

Post by Henry Story
quickly and show how these fit together. I argued for it here

http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid

Post by Henry Story
but there are many aspects to it. A face to face can't harm.
Henry

Post by Francisco Corella
Harry,

Post by Harry Halpin

Post by Francisco Corella
This thread shows that a workshop on user certificates would be
useful. Are you still planning on having one this spring, or have
you given up on that?

We'll see. It depends on how the Web Crypto WG goes, some amount
(although not everything talked about on this mailing list)
certificate handling is in "secondary features" so I see no real
reason for another workshop at this point unless it seems another WG
is necessary to do that work.

The Web Crypto WG is about a JavaScript API. Issuing and using
certificates should not require JavaScript. TLS client certificates
are not a JavaScript feature. The <keygen> element, a building block
for certificate issuance, is not a JavaScript feature. It is possible
today to issue a certificate automatically to at least one browser
(Firefox) without JavaScript, although not securely.
A workshop would help you decide whether a WG is needed; and it would
be useful to get the people interested in certificates in one room,
whether or not a WG follows.
Francisco

Social Web Architect
http://bblfish.net/

David Dahl

2012-03-21 21:10:52 UTC

Permalink

----- Original Message -----

Sent: Wednesday, March 21, 2012 3:17:55 PM
Subject: Re: Beyond HTTP Authentication: OAuth, OpenID, and BrowserID: Meeting on March 29th at IETF83

Post by Anders Rundgren
Mozilla's crypto.signText () is IMO a better JS+X.509 fit than DOMCrypt.
They build on quite different principles.

DOMCrypt can be whatever we want it to be. Nothing locks its future
expansions into being solely domain-based.

Indeed. There is no reason to rule out additional methods for working with/importing/exporting certificates. The WG is just getting started.

Cheers,

David

Anders Rundgren

2012-03-22 05:59:13 UTC

Permalink

Post by David Dahl
----- Original Message -----

Sent: Wednesday, March 21, 2012 3:17:55 PM
Subject: Re: Beyond HTTP Authentication: OAuth, OpenID, and BrowserID: Meeting on March 29th at IETF83

Post by Anders Rundgren
Mozilla's crypto.signText () is IMO a better JS+X.509 fit than DOMCrypt.
They build on quite different principles.

DOMCrypt can be whatever we want it to be. Nothing locks its future
expansions into being solely domain-based.

Indeed. There is no reason to rule out additional methods for working
with/importing/exporting certificates. The WG is just getting started.

This sounds scary. I hope you are wise enough to define a version #1 and get
that out of the door in time before taking on a next step which I think will
prove to be "slightly" worse. For certificates the WG will be facing a bunch
of very different and partially competing solutions.

I still don't see that there are particularly many use-cases for addressing
certificates from *untrusted browser-code*. My experiences with "CertEnroll"
indicates that this is a very messy thing that introduces security and privacy
issues that you don't want to deal with in future browsers. In Windows 7
Microsoft have also added an XML-based protocol replacement. No API.

For that very reason my two contributions to this field, WASP and KeyGen2
were designed as distinct high-level do-it-all-functions that carry out
their duties in trusted code. This is essentially what crypto.signText ()
does as well although WASP takes it one step further by doing the sending
as well (WASP signatures are "targeted").

Anders

Post by David Dahl
Cheers,
David

Anders Rundgren

2012-03-22 08:17:57 UTC

Permalink

Post by Francisco Corella
Harry,
This thread shows that a workshop on user certificates would be useful. Are you still planning on having one this spring, or have you given up on that?

We'll see. It depends on how the Web Crypto WG goes, some amount (although not everything talked about on this mailing list) certificate handling is in "secondary features" so I see no real reason for
another workshop at this point unless it seems another WG is necessary to do that work.

Don't we need at least one "input document" to take on a new topic?

I'm FWIW not particularly inclined accepting claims that you can extend DOMCrypt
for usage with traditional PKI until we get some more concrete proposals on how
this {c|w}ould work including some applicable use-cases. It is IMHO a waste of
the other parties' precious time not producing the necessary write-ups.

Anders

Post by Francisco Corella
Thanks,
Francisco

Harry Halpin

2012-03-20 12:50:05 UTC

Permalink

Thanks Anders, I'll give this a look over before the meeting!

Post by Anders Rundgren
thanx,
Anders Rundgren
http://webpki.org/auth-token-4-the-cloud.html

GALINDO Virginie

2012-03-20 14:44:39 UTC

Permalink

Dear all,

Few things about this conversation from gemalto perspective:

* Call to discussion in IETF
Unfortunately gemalto will not attend next week IETF meeting, but would be pleased to get feedback from the planned discussions. Harry, we rely on you to share the expressed requirements to feed discussions in the Web Crypto API WG, when kicked off...

* Secure storage
Several means to perform secure storage are existing depending on the targeted storage. As an example, invoking storage in trusted execution environment is described in GlobalPlatform specifications related to TEE [1], storage in secure element inserted in a mobile device is described in Open Mobile API delivered by the SIMAlliance [2] , and storage in TPM/MTM are described in TCGs specifications [3]. And in addition each operating system is providing some specific APIs to store locally some data . As a first step, an API providing an abstract layer to those different type of storage would definitely be beneficial to the industry, and this is why gemalto is supporting this activity in W3C (but as I have already mentioned in this mailing list, this will not help if we stop in the middle of the road, we might get this API rich enough to allow any type of storage, taking into account their security resistance).

* On availability of smart card
SDKs and smart card samples are available on any smart card vendor (and not only gemalto one). Getting samples is just a matter of having the right contact, (me for example :-). Feel free to contact me, to see how we can support you.

* on the standardization of key provisioning
As security provider, we have a certain experience of "enrollment and key provisioning in tokens", and something we learned by serving our customer is that key provisioning can sometimes have benefits to be 'standard', but need also to be flexible enough to answer specific customer requirements/injection constraints/certification schemes. And this is where you realize that it is a real job, not just a matter of having an API ;-)
In the recent past, the security industry has been standardizing the generation of keys in a token for third parties who do not want the token issuer to see the keys. This is described in GlobalPlatform "Confidential Card Content Management Card Specification v2.2 - Amendment A Version 1.0.1" [4], but it is the maximum that industry has accepted to standardize. Scenarios for pushing or pulling new keys in the token may look like ideas/principles captured by Mo blog.

Hope it clarifies some points.
Regards,
Virginie
Gemalto
+33613232003

[1] http://www.globalplatform.org/specificationsdevice.asp
[2] http://www.simalliance.org/en/resources/specifications/
[3] http://www.trustedcomputinggroup.org/
[4] http://www.globalplatform.org/specificationscard.asp

-----Original Message-----
From: Harry Halpin [mailto:hhalpin-***@public.gmane.org]
Sent: mardi 20 mars 2012 13:50
To: Anders Rundgren
Cc: public-identity-***@public.gmane.org
Subject: Re: Beyond HTTP Authentication: OAuth, OpenID, and BrowserID: Meeting on March 29th at IETF83

Post by Anders Rundgren
I won't make it to IETF 83. Here comes a short presentation
http://openkeystore.googlecode.com/svn/trunk/resources/docs/tee-se-com
bo.pdf
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

Thanks Anders, I'll give this a look over before the meeting!

Post by Anders Rundgren
thanx,
Anders Rundgren
http://webpki.org/auth-token-4-the-cloud.html

Post by Harry Halpin
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.
=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.

Anders Rundgren

2012-03-20 21:13:32 UTC

Permalink

Hi Virginie,

Regarding standardization of key provisioning I'm advocating a solution
that covers 80% of the (perceived) market. The 20% case will most
likely lead to a crummy design and is better covered by custom solutions.

In reality cost factors will probably make coverage 95% and that
is in my mind a 100% success :-)

Anders

Post by GALINDO Virginie
Dear all,
* Call to discussion in IETF
Unfortunately gemalto will not attend next week IETF meeting, but would be pleased to get feedback from the planned discussions. Harry, we rely on you to share the expressed requirements to feed discussions in the Web Crypto API WG, when kicked off...
* Secure storage
Several means to perform secure storage are existing depending on the targeted storage. As an example, invoking storage in trusted execution environment is described in GlobalPlatform specifications related to TEE [1], storage in secure element inserted in a mobile device is described in Open Mobile API delivered by the SIMAlliance [2] , and storage in TPM/MTM are described in TCGs specifications [3]. And in addition each operating system is providing some specific APIs to store locally some data . As a first step, an API providing an abstract layer to those different type of storage would definitely be beneficial to the industry, and this is why gemalto is supporting this activity in W3C (but as I have already mentioned in this mailing list, this will not help if we stop in the middle o

f the road, we might get this API rich enough to allow any type of storage, taking into account their security resistance).

Post by GALINDO Virginie
* On availability of smart card
SDKs and smart card samples are available on any smart card vendor (and not only gemalto one). Getting samples is just a matter of having the right contact, (me for example :-). Feel free to contact me, to see how we can support you.
* on the standardization of key provisioning
As security provider, we have a certain experience of "enrollment and key provisioning in tokens", and something we learned by serving our customer is that key provisioning can sometimes have benefits to be 'standard', but need also to be flexible enough to answer specific customer requirements/injection constraints/certification schemes. And this is where you realize that it is a real job, not just a matter of having an API ;-)
In the recent past, the security industry has been standardizing the generation of keys in a token for third parties who do not want the token issuer to see the keys. This is described in GlobalPlatform "Confidential Card Content Management Card Specification v2.2 - Amendment A Version 1.0.1" [4], but it is the maximum that industry has accepted to standardize. Scenarios for pushing or pulling new keys in the token may look like ideas/principles captured by Mo blog.
Hope it clarifies some points.
Regards,
Virginie
Gemalto
+33613232003
[1] http://www.globalplatform.org/specificationsdevice.asp
[2] http://www.simalliance.org/en/resources/specifications/
[3] http://www.trustedcomputinggroup.org/
[4] http://www.globalplatform.org/specificationscard.asp
-----Original Message-----
Sent: mardi 20 mars 2012 13:50
To: Anders Rundgren
Subject: Re: Beyond HTTP Authentication: OAuth, OpenID, and BrowserID: Meeting on March 29th at IETF83

Post by Anders Rundgren
I won't make it to IETF 83. Here comes a short presentation
http://openkeystore.googlecode.com/svn/trunk/resources/docs/tee-se-com
bo.pdf
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

Thanks Anders, I'll give this a look over before the meeting!

Post by Anders Rundgren
thanx,
Anders Rundgren
http://webpki.org/auth-token-4-the-cloud.html

Post by Harry Halpin
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.
=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.