Re: Charter Text Confusion

> Hi all,
>
> I again read through the charter text and noticed that only the JavaScript
> CryptoAPI work is roughly understandable for me (since I had been at the
> W3C Identity in the Browser workshop). Even with this item there was some
> amount of discussion at the workshop about would exactly be done as part
> of this activity. While the workshop took place many months ago I have not
> seen the scope clarified anywhere.


Clarifying the scope is part of the chartering process at W3C. We have
until the end of Nov. to work out a draft charter with scope. We will be
following the voting results of the end of the workshop on a broad scale
for scope (i.e. a focus on crypto and JS APIs), but the details are up for
debate.

>
> The only requirements alike writeup I am aware of is
> http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_28.pdf
>
> Wouldn't it make sense to have at least the scope clarified before going
> into the details of the work as part of the chartering process? For
> example, I would be interested whether the access to key storage and smart
> cards is considered within the scope of the group.


Re keystorage, it's is tricky as keystorage is usually handled by
low-level libraries such as NSS [1]. I do think key storage is within
scope. Ideally, we'd want the API to serve as a generic API across
different platform and browser-specific libraries. I While these libraries
are not part of the browser per se and generally pre-existing, I would say
guidelines and security considerations for the use of these libraries
should be included.

As for smartcards (and other things such as USB media), I'm more
borderline about scope. Anders had some ideas and I'd be happy to hear
from him if he could be constructive rather than complain.  An alternative
approach to DomCrypt would be the proposed (and unimplemented, I believe)
Web Crypto API [2]. It contains draft API calls for loading keys off of
smartcards. I think whether or not that should be included is up for to
debate.

>
> Then, the subsequent items in the charter are in my view badly described.
> Hence, it is not surprising that most of the messages exchanged on this
> list are actually off-topic.

I think we may then need some introductory information. First, we should
probably separate authentication from authorization.  Then, in general
identity can be seen as attaching a session token to an identifier. In
Mozilla's APIs, this is done via attaching a "verified email address" to a
"cookie" which has generally been produced by password-based
authentication. We could imagine attaching stronger kinds authentication
credentials (i.e. public-private key) to different kinds of tokens (even
going from cookies to client certs) and attaching these to other kinds of
identifiers (as done in OpenID Connect).

Session state is then generally if one is "logged-in", "logged-out" of a
session.

Does anyone want to draft this introductory session that defines terms?

Generally it seems Identity API should be discussed before Sync in the
charter, unless there's objections I'll change that.

Let's nail this introductory text down before we change the draft text
around Sync and the Identity API.


>
> Is there a problem description of what Web Identity Sync should do? Is
> Mozilla's implementation sufficient to do standardization work in that
> area? Isn't the purpose of standardization to let various different
> implementations to interwork? Given that the term "identity" is very weak
> defined (in general, not only in the W3C) this item could essentially be
> anything.


On the side, Sync's use-case is that if these credentials are limited to a
single device, that really limits their usage. Ideally, a user wants to
have their identifiers usable across multiple devices, so that when you
create an identity with some stored passwords (or beyond) on one browser
in your smartphone, you can transfer those to a new desktop with a
different browser. Consider it currently cookie transfer between browsers,
although one could imagine different kinds of session tokens and even
credentials being transferred.  Does that use-case make sense?

>
> For the Identity API has anyone bothered to write down a list of
> requirements about what API functionality is generic among different
> identity protocols and should therefore be standardized? Given that
> JavaScript can do almost anything I fear that some folks on this list try
> to standardize their favorite protocol as part of this "API" work.

See above.
>
> Finally, I do not understand why a single charter needs to contain all
> these items? Why isn't it possible to have a more focused charter and get
> some work done in a proper way rather than establishing an open-ended
> group?
>
> Everyone who had even done some work in the identity management area knows
> that the term "identity" has to be avoided at all cost.
>

[1]http://www.mozilla.org/projects/security/pki/nss/
[2]http://html5.creation.net/webcrypto-api/


> Ciao
> Hannes
>
>
>

Received on Wednesday, 26 October 2011 21:17:25 UTC