On Tue, Nov 12, 2013 at 12:34 PM, Lloyd Hilaiel <lhil...@mozilla.com> wrote:
> Goal: we should determine if there are any small high value tweaks we can make to data formats, especially those that give us future flexibility to make changes, or make it significantly easier to work with the formats.

On the assumption we're talking about the Persona formats here, CC'ing
dev-identity...

I have an initial write-up of data format changes here:

https://github.com/djc/id-specs/blob/prod/browserid/json-formats.md

It seems like the biggest issue is the use of the DS128 signature
algorithm in identity assertions. I presume these were used for the
per-user property stuff that DSA can do (well, I looked it up on
Wikipedia a little), but this algorithm is not supported in current
JWS. I'm not sure exactly why DSA was chosen here, what the current
status of its security is, or why it's not supported in JWS. If we're
still okay with it, we could consider asking the JOSE guys to include
it, submitting it to their registry. Otherwise, we'd have to move to
RSA or ECDSA (with only the NIST curves explicitly supported in
current drafts).

At the same time, using current JWS with an unsupported algorithm
would IMO be a good upgrade over the current state.

I'm also happy to look into getting jwcrypto/browserid to accept these
new formats, and normalize based on the differences listed in the
document.

Cheers,

Dirkjan

On Nov 12, 2013, at 2:59 PM, Dirkjan Ochtman <dir...@ochtman.nl> wrote:

> On Tue, Nov 12, 2013 at 12:34 PM, Lloyd Hilaiel <lhil...@mozilla.com> wrote:
>> Goal: we should determine if there are any small high value tweaks we can make to data formats, especially those that give us future flexibility to make changes, or make it significantly easier to work with the formats.
>
> On the assumption we're talking about the Persona formats here, CC'ing
> dev-identity...
>
> I have an initial write-up of data format changes here:
>
> https://github.com/djc/id-specs/blob/prod/browserid/json-formats.md
>
> It seems like the biggest issue is the use of the DS128 signature
> algorithm in identity assertions. I presume these were used for the
> per-user property stuff that DSA can do (well, I looked it up on
> Wikipedia a little), but this algorithm is not supported in current
> JWS. I'm not sure exactly why DSA was chosen here, what the current
> status of its security is, or why it's not supported in JWS. If we're
> still okay with it, we could consider asking the JOSE guys to include
> it, submitting it to their registry. Otherwise, we'd have to move to
> RSA or ECDSA (with only the NIST curves explicitly supported in
> current drafts).

We chose DSA primarily for its performance properties.  Specifically, an average old xp machine can’t generate an RSA key pair in javascript without the user seeing warnings about runaway javascript computation.

On 11/12/13 8:02 AM, Lloyd Hilaiel wrote:
> We chose DSA primarily for its performance properties. Specifically,
> an average old xp machine can’t generate an RSA key pair in javascript
> without the user seeing warnings about runaway javascript computation.

Do you need to support browsers that don't have workers and just push
this task off onto a worker?

--BDS

Benjamin Smedberg <benj...@smedbergs.us> wrote:
>On 11/12/13 8:02 AM, Lloyd Hilaiel wrote:
>> We chose DSA primarily for its performance properties. Specifically,
>> an average old xp machine can’t generate an RSA key pair in
>javascript
>> without the user seeing warnings about runaway javascript
>computation.
>Do you need to support browsers that don't have workers

Yeah.  

 and just push
>this task off onto a worker?

Even with workers, we need an acceptable user delay.  Don't believe we get that on fxos nor IE with RSA.  

Lloyd

>--BDS

lloyd - (on an tiny keyboard)

On 12 Nov 2013, at 11:59 pm, Dirkjan Ochtman <dir...@ochtman.nl> wrote:

> still okay with it, we could consider asking the JOSE guys to include
> it, submitting it to their registry. Otherwise, we'd have to move to
> RSA or ECDSA (with only the NIST curves explicitly supported in
> current drafts).

I'm sure it could be specified in a separate document.

-- Luke

On 12/11/13 04:59, Dirkjan Ochtman wrote:
> I have an initial write-up of data format changes here:
>
> https://github.com/djc/id-specs/blob/prod/browserid/json-formats.md

Wow, thanks so much for going through this!

I was just talking to Danny and there's something in Fx Accounts that's
going to be annoying with respect to the "principal -> sub" change in
the certificate format.

They are currently adding another field ("uuid") in that array, next to
"email". If the principal array goes away and is replaced by a "sub"
string, then they would have to find a different place to put that
identifier.

Francois

On Tue, Nov 12, 2013 at 10:29 PM, Francois Marier <fran...@mozilla.com> wrote:
> I was just talking to Danny and there's something in Fx Accounts that's
> going to be annoying with respect to the "principal -> sub" change in
> the certificate format.
>
> They are currently adding another field ("uuid") in that array, next to
> "email". If the principal array goes away and is replaced by a "sub"
> string, then they would have to find a different place to put that
> identifier.

We can definitely just make it {"email": "us...@example.com", "uuid":
"e7f39b30-4be6-11e3-8f96-0800200c9a66"} (i.e. keep the JSON object).
It's just that I hadn't seen any other usage, so I assumed we could
simplify. Obviously if we have a good use case we should keep it as
is.

BTW, I asked the JOSE people, and they definitely seem to think we can
easily get DS128 added to the registry as a signing algorithm. I also
proposed adding non-NIST elliptic curves; e.g. Ed25519 gets pretty
good performance as well, and may have better security.

Cheers,

Dirkjan

On Nov 12, 2013, at 2:11 PM, Dirkjan Ochtman <dir...@ochtman.nl> wrote:

> On Tue, Nov 12, 2013 at 10:29 PM, Francois Marier <fran...@mozilla.com> wrote:
>> I was just talking to Danny and there's something in Fx Accounts that's
>> going to be annoying with respect to the "principal -> sub" change in
>> the certificate format.
>>
>> They are currently adding another field ("uuid") in that array, next to
>> "email". If the principal array goes away and is replaced by a "sub"
>> string, then they would have to find a different place to put that
>> identifier.
>
> We can definitely just make it {"email": "us...@example.com", "uuid":
> "e7f39b30-4be6-11e3-8f96-0800200c9a66"} (i.e. keep the JSON object).
> It's just that I hadn't seen any other usage, so I assumed we could
> simplify. Obviously if we have a good use case we should keep it as
> is.

UUID is an example of an (optional) attribute that an IdP might want to include in the response.

I'm not sure whether BrowserID wants to make additional attributes more formally specified or not.

E.g., OpenID has a facility for this: http://openid.net/specs/openid-attribute-exchange-1_0.html

But Firefox Accounts needs to signal the email as well as the UID, so we need some way to do it.

-chris

> BTW, I asked the JOSE people, and they definitely seem to think we can
> easily get DS128 added to the registry as a signing algorithm. I also
> proposed adding non-NIST elliptic curves; e.g. Ed25519 gets pretty
> good performance as well, and may have better security.
>
> Cheers,
>
> Dirkjan

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity

> On Tue, Nov 12, 2013 at 10:29 PM, Francois Marier <fran...@mozilla.com> wrote:
>> I was just talking to Danny and there's something in Fx Accounts that's
>> going to be annoying with respect to the "principal -> sub" change in
>> the certificate format.
>>
>> They are currently adding another field ("uuid") in that array, next to
>> "email". If the principal array goes away and is replaced by a "sub"
>> string, then they would have to find a different place to put that
>> identifier.
>
> We can definitely just make it {"email": "us...@example.com", "uuid":
> "e7f39b30-4be6-11e3-8f96-0800200c9a66"} (i.e. keep the JSON object).
> It's just that I hadn't seen any other usage, so I assumed we could
> simplify. Obviously if we have a good use case we should keep it as
> is.

You could put the UUID as a top-level claim, that's probably simplest.

Myself, I liked the principal sub-object as we use that for Persona host certificates (e.g. "hostname" attribute). But that's not a use case for you and I wouldn't want to delay standardisation by arguing for it.

-- Luke

yeah, in working with the payswarm folks, they need this feature too.  In reading the jw* specs, it looked like new top level claims was the way to go that is inline with the specs.

That said, we may want to add a fxa top level key and keep fxa specific claims under a namespace.

No strong feelings, but I think we need this feature sooner than later.  I’d be happy to expose it in the jwcrypto apis as well if useful.

lloyd


>
> -- Luke

On Wed, Nov 13, 2013 at 1:31 PM, Lloyd Hilaiel <lhil...@mozilla.com> wrote:
>> You could put the UUID as a top-level claim, that's probably simplest.
>>
>> Myself, I liked the principal sub-object as we use that for Persona host certificates (e.g. "hostname" attribute). But that's not a use case for you and I wouldn't want to delay standardisation by arguing for it.
>
> yeah, in working with the payswarm folks, they need this feature too.  In reading the jw* specs, it looked like new top level claims was the way to go that is inline with the specs.
>
> That said, we may want to add a fxa top level key and keep fxa specific claims under a namespace.

Are these actually claims, though? Is the "uuid" property used to
assert that a certain entity has that UUID as a property, or is it
used to designate an FxA user which has that UUID as his/her
identifier? If the former, I think it makes sense to make "uuid" a
top-level claim, but if the latter, it should be part of the value for
the "sub" key.

Cheers,

Dirkjan

Dirkjan,

It's the latter. It's intended to signal that the FxA user has the specified user id.

So, e.g.,

sub: {
  email: "f...@mozilla.com",
  uid: "f3b5e080-4cc8-11e3-88bf-0002a5d5c51b"
}

would be perfect for us.

-chris


> Cheers,
>
> Dirkjan

> It's the latter. It's intended to signal that the FxA user has the specified user id.
>
> So, e.g.,
>
> sub: {
>  email: "f...@mozilla.com",
>  uid: "f3b5e080-4cc8-11e3-88bf-0002a5d5c51b"
> }

Maybe "uuid" or "guid" is better than "uid", as "uid" can mean a bunch of different things (number UIDs in POSIX, flat user names in LDAP, etc). But it probably doesn't matter...

-- Luke

On Thu, Nov 14, 2013 at 2:08 AM, Chris Karlof <cka...@mozilla.com> wrote:
> It's the latter. It's intended to signal that the FxA user has the specified user id.

Thanks for the clarification. I've added back the the object in the
latest version of the document.

Cheers,

Dirkjan

On 11/14/2013 03:08 AM, Chris Karlof wrote:
> On Nov 13, 2013, at 6:06 AM, Dirkjan Ochtman <dir...@ochtman.nl> wrote:
>
>> On Wed, Nov 13, 2013 at 1:31 PM, Lloyd Hilaiel <lhil...@mozilla.com> wrote:
>>>> You could put the UUID as a top-level claim, that's probably simplest.
>>>>
>>>> Myself, I liked the principal sub-object as we use that for Persona host certificates (e.g. "hostname" attribute). But that's not a use case for you and I wouldn't want to delay standardisation by arguing for it.
>>> yeah, in working with the payswarm folks, they need this feature too.  In reading the jw* specs, it looked like new top level claims was the way to go that is inline with the specs.
>>>
>>> That said, we may want to add a fxa top level key and keep fxa specific claims under a namespace.
>> Are these actually claims, though? Is the "uuid" property used to
>> assert that a certain entity has that UUID as a property, or is it
>> used to designate an FxA user which has that UUID as his/her
>> identifier? If the former, I think it makes sense to make "uuid" a
>> top-level claim, but if the latter, it should be part of the value for
>> the "sub" key.
>>
> Dirkjan,
>

> It's the latter. It's intended to signal that the FxA user has the specified user id.
>

> So, e.g.,
>
> sub: {
>    email: "f...@mozilla.com",
>    uid: "f3b5e080-4cc8-11e3-88bf-0002a5d5c51b"
> }
>

> would be perfect for us.

To be inline with extensibility prescriptions in JWS sections 4.2 and
4.3 (that you create new top level properties to extend), and to be
within the spec for `sub` [1], we might want to instead consider:

sub: "f...@mozilla.com",
fxa: { "uid": "f3b5e080-4cc8-11e3-88bf-0002a5d5c51b" }

This makes generic parsing easier, and gives us a clear simple way to
support IdP's extending the certificate with properties that RP's MAY
choose to use.

lloyd

[1] "The "sub" value is a case-sensitive string containing a StringOrURI
value."
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-13#section-4.1.2

lloyd

-chris
>> Cheers,
>>
>> Dirkjan
>> _______________________________________________
>> dev-identity mailing list
>> dev-id...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-identity

--
--lloyd

Have you looked at openid connect's id_token?
http://openid.net/specs/openid-connect-core-1_0.html#IDToken
Most of the id_token's fields are optional and the required one make sense
in most protocols I think.

The uuid would go into the sub field. email is email.

  {
   "iss": "http://server.example.com",
   "sub": "f3b5e080-4cc-11e3-88bf-0002a5d5c51b",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "gender": "female",
   "birthdate": "0000-10-31",
   "email": "jan...@example.com",
   "picture": "http://example.com/janedoe/me.jpg"
  }

-Axel




2013/11/20 Lloyd Hilaiel <ll...@mozilla.com>

On 11/13/13 8:33 PM, Luke Howard wrote:

> Maybe "uuid" or "guid" is better than "uid", as "uid" can mean a bunch
> of different things (number UIDs in POSIX, flat user names in LDAP,
> etc). But it probably doesn't matter...

Yeah, I'd like to see "fxa" in there somewhere, either Lloyd's "fxa.uid"
proposal or "principal.fxa_uid".

cheers,
 -Brian

+1 for some kind of namespacing

----
Typed with my thumb

On 11/12/13 2:11 PM, Dirkjan Ochtman wrote:

> BTW, I asked the JOSE people, and they definitely seem to think we can
> easily get DS128 added to the registry as a signing algorithm. I also
> proposed adding non-NIST elliptic curves; e.g. Ed25519 gets pretty
> good performance as well, and may have better security.

Ed25519 is by far my favorite signing algorithm (fast, high-security,
short keys, short signatures). It isn't in SJCL, but there are a few JS
ports floating around: http://www.flownet.com/ron/code/fast-djbec.js .
I'd love to see it in JOSE.

cheers,
 -Brian

+0 on namespacing. I like flat and so does openid connect, apparently.

Thanks Axel.

-chris

> [1] "The "sub" value is a case-sensitive string containing a StringOrURI value." http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-13#section-4.1.2
>
> lloyd
>
>
> -chris
> Cheers,
>
> Dirkjan

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
>

> --
> --lloyd

Chris’s current proposal [1] is for FxA assertions:
{
  "sub": "f3b5e080-4cc-11e3-88bf-0002a5d5c51b”,
  “email”: “ll...@example.com”
}

I am +0 to expressing an FxA specific UUID in “sub”.  I think it’s well within the intent of the spec ("The subject value MAY be scoped to be locally unique in the context of the issuer“).  But because `sub` is optional, I would be equally happy with “fxa_uuid” or “fxaid” - Defer to chris.

I am on board with this proposal if we change Persona’s data formats to not use `sub` nor `principal` and instead express emails as:
{
  “email”: “ll...@example.com”
}

(for bonus points, we could then see if we can have `email` (probably have to call it `eml`) as a “public” optional field in the jet spec.)

lloyd

On 21 Nov 2013, at 7:17 pm, Lloyd Hilaiel <lhil...@mozilla.com> wrote:

> Chris’s current proposal [1] is for FxA assertions:
> {
>  "sub": "f3b5e080-4cc-11e3-88bf-0002a5d5c51b”,
>  “email”: “ll...@example.com”
> }
>
> I am +0 to expressing an FxA specific UUID in “sub”.  I think it’s well within the intent of the spec ("The subject value MAY be scoped to be locally unique in the context of the issuer“).  But because `sub` is optional, I would be equally happy with “fxa_uuid” or “fxaid” - Defer to chris.

If it's just an opaque unique identifier for identifying the certified identity, I think that using "sub" is preferable to defining a new claim. If the UUID has specific meaning within FxA, then a separate claim might be better.

> I am on board with this proposal if we change Persona’s data formats to not use `sub` nor `principal` and instead express emails as:
> {
>  “email”: “ll...@example.com”
> }

+1

> (for bonus points, we could then see if we can have `email` (probably have to call it `eml`) as a “public” optional field in the jet spec.)

"email" is fine IMO. It's consistent with the OpenID Connect spec referenced earlier in this thread.

-- Luke

On Thu, Nov 21, 2013 at 9:17 AM, Lloyd Hilaiel <lhil...@mozilla.com> wrote:
> Chris’s current proposal [1] is for FxA assertions:

I think you forgot to include the reference:

https://github.com/mozilla/fxa-auth-server/pull/275#issuecomment-28964578

In that issue, I've argued that I don't think this is the best solution:

JWT is a standard for signing claims about subjects. IMO if we're
going to use that standard, we should try to use it the way it's
intended; if we don't, then it would be better to invent a whole
different thing to prevent confusion.

If FxA needs to claim things about non-email UIDs, and Persona needs
to claim things about email addresses, then it seems perfectly fine to
me to have both use the "sub" field in different ways. FxA could use
an "email" property to claim that the UID in "sub" corresponds to an
account related to that email address.

Cheers,

Dirkjan

On Nov 21, 2013, at 10:36 AM, Dirkjan Ochtman <dir...@ochtman.nl> wrote:

> On Thu, Nov 21, 2013 at 9:17 AM, Lloyd Hilaiel <lhil...@mozilla.com> wrote:
>> Chris’s current proposal [1] is for FxA assertions:
>
> I think you forgot to include the reference:
>
> https://github.com/mozilla/fxa-auth-server/pull/275#issuecomment-28964578

Thanks for keeping all the threads tied together, djc!  

> In that issue, I've argued that I don't think this is the best solution:
>
> JWT is a standard for signing claims about subjects. IMO if we're
> going to use that standard, we should try to use it the way it's
> intended; if we don't, then it would be better to invent a whole
> different thing to prevent confusion.
>
> If FxA needs to claim things about non-email UIDs, and Persona needs
> to claim things about email addresses, then it seems perfectly fine to
> me to have both use the "sub" field in different ways. FxA could use
> an "email" property to claim that the UID in "sub" corresponds to an
> account related to that email address.

Yeah, great point.

It seems like we have two ways to confuse people here:
1. those familiar with JWT who expect a *subject* to emerge from JWT processing to not find one.
2. those familiar with one of Persona or FxA who expect an *email* to emerge to not find one.

In either case, we’ve got a problem to mitigate.  I no longer feel strongly here.  If chris and dan want to consider all this and choose good starting approaches for FxA and Persona respectively, then I’m on board.

I guess for me, the really interesting decision point is the if we would choose to start emitting assertions from FxA that *lack* an `email` field.  That’s when 3rd party service providers who want to play really get stuck - when they’ve got a user that they cannot authenticate via a means other than FxA, and are effectively locked in.  But that decision point is in the future.

lloyd

> Cheers,
>
> Dirkjan

On Thu, Nov 21, 2013 at 9:51 AM, Lloyd Hilaiel <lhil...@mozilla.com> wrote:
> I guess for me, the really interesting decision point is the if we would choose to start emitting assertions from FxA that *lack* an `email` field.  That’s when 3rd party service providers who want to play really get stuck - when they’ve got a user that they cannot authenticate via a means other than FxA, and are effectively locked in.  But that decision point is in the future.

Very much agreed.

Cheers,

Dirkjan

On Thu, Nov 21, 2013 at 9:51 AM, Lloyd Hilaiel <lhil...@mozilla.com> wrote:
> It seems like we have two ways to confuse people here:
> 1. those familiar with JWT who expect a *subject* to emerge from JWT processing to not find one.
> 2. those familiar with one of Persona or FxA who expect an *email* to emerge to not find one.

As for this, I think this is something that shouldn't be handled at
the data format layer, but at the API layer. That is, FxA APIs that
deal with JWTs at the low level can make sure to provide a clear
contract about email vs UID, and Persona APIs can provide a clear
contract that deals with just emails. The JWT format is at a lower
level and has a clear concept that I think is valuable to adhere to.

Cheers,

Dirkjan

A remark regarding uuid:
IdPs introduce UUIDs because sometimes they recycle email addresses (latest
infamous example: YAHOO!).
So asserting that an email address is currently owned by a subject might
not be enough.
The property of the UUID is that is unique and NEVER reused.

For this reason Persona might want assertions that contain both sub (UUID)
and email.

Relying Parties (assertion consumers) are advised to use the value of sub
as their user database primary key and never email.
For the same reason that email are reused by other subjects.

-Axel


2013/11/21 Dirkjan Ochtman <dir...@ochtman.nl>

On Thu, Nov 21, 2013 at 11:36 AM, Axel Nennker <ignis...@gmail.com> wrote:
> IdPs introduce UUIDs because sometimes they recycle email addresses (latest
> infamous example: YAHOO!).
> So asserting that an email address is currently owned by a subject might not
> be enough.
> The property of the UUID is that is unique and NEVER reused.
>
> For this reason Persona might want assertions that contain both sub (UUID)
> and email.

I don't think what you're saying makes sense in the context of the
BrowserID protocol used by Persona. Since BrowserID is exclusively
used to prove ownership of an email address, there is no stable UUID
involved.

Cheers,

Dirkjan

On 21 Nov 2013, at 9:40 pm, Dirkjan Ochtman <dir...@ochtman.nl> wrote:

> I don't think what you're saying makes sense in the context of the
> BrowserID protocol used by Persona. Since BrowserID is exclusively
> used to prove ownership of an email address, there is no stable UUID
> involved.

IdPs could include a UUID, but unless it's federated somehow (e.g. UUID@IdP), then it's impossible to avoid an IdP spoofing a user from a different administrative domain.

-- Luke

Federation comes later I think.
The user db might have a table of UUIDs for each Idp.

-Axel


2013/11/21 Luke Howard <lu...@padl.com>

On 21 Nov 2013, at 10:04 pm, Axel Nennker <ignis...@gmail.com> wrote:

> Federation comes later I think.
> The user db might have a table of UUIDs for each Idp.

Ah, true. Given Persona protocol is based on verifying the issuer of an email address,* I think this and consistency with OpenID Connect speak in favour of using an "email" claim rather than "sub".

-- Luke

* or something that looks like one

On Thu, Nov 21, 2013 at 12:14 PM, Luke Howard <lu...@padl.com> wrote:
> Ah, true. Given Persona protocol is based on verifying the issuer of an email address,* I think this and consistency with OpenID Connect speak in favour of using an "email" claim rather than "sub".

I disagree. OpenID Connect is using a token to claim that a certain
email address belongs to a certain user identified by an opaque UUID.
In the BrowserID protocol used for Persona, we very explicitly chose
to use the email address as a transparent user ID. Therefore, if we
claim things about the user or session, we should use the email
address as the claim subject.

Cheers,

Dirkjan

> I disagree. OpenID Connect is using a token to claim that a certain
> email address belongs to a certain user identified by an opaque UUID.
> In the BrowserID protocol used for Persona, we very explicitly chose
> to use the email address as a transparent user ID. Therefore, if we
> claim things about the user or session, we should use the email
> address as the claim subject.

OK, that also makes sense. :)

-- Luke

The email I was answering to was arguing that some expect sub in an
assertion and some expect email in an assertion.
In my email I wanted to express that there might be a reason to have both
because the IdP might recycle email addresses.
I guess all this is known and has been discussed before.


2013/11/21 Dirkjan Ochtman <dir...@ochtman.nl>

> On Thu, Nov 21, 2013 at 11:36 AM, Axel Nennker <ignis...@gmail.com>
> wrote:
> > IdPs introduce UUIDs because sometimes they recycle email addresses
> (latest
> > infamous example: YAHOO!).
> > So asserting that an email address is currently owned by a subject might
> not
> > be enough.
> > The property of the UUID is that is unique and NEVER reused.
> >
> > For this reason Persona might want assertions that contain both sub
> (UUID)
> > and email.
>

> I don't think what you're saying makes sense in the context of the
> BrowserID protocol used by Persona. Since BrowserID is exclusively
> used to prove ownership of an email address, there is no stable UUID
> involved.
>

> Cheers,
>
> Dirkjan
>

openid connect does not care about which identifier the user uses to
authenticate. It can be an email address but this is left to the
authentication system.
browserid uses the user's email address in the UI because that is what is
easiest for users.

an openid connect token is like a browserid assertion which optionally can
contain an email address.
The sub field in openid connect assertions is "owned" by the IdP. It can be
an email address but this gets tricky if email are ever recycled.

Users never understood urls as ids (openid1/2) and email addresses are what
users understand and know without looking it up. That was the reason Ben
et.al. chose email addresses.
I think that does not preclude the usage of uuid/ppid/sub in the browserid
protocol that are not emails.
The user never sees this. The RP benefits from a permanent, never changing
sub.

-Axel




2013/11/21 Dirkjan Ochtman <dir...@ochtman.nl>

> On Thu, Nov 21, 2013 at 12:14 PM, Luke Howard <lu...@padl.com> wrote:
> > Ah, true. Given Persona protocol is based on verifying the issuer of an
> email address,* I think this and consistency with OpenID Connect speak in
> favour of using an "email" claim rather than "sub".
>

> Cheers,
>
> Dirkjan
>