Announcing Mozilla Persona

[Dan Mills]

Hi all,

I wanted to let you know that today we announced Mozilla Persona, a new name for the complete identity offering from Mozilla. Read more about it at our blog:

http://identity.mozilla.com/post/18038609895/introducing-mozilla-persona



BrowserID will stay as a technology name, but the consumer-facing brand of our service will fall under the Persona brand. You can think about it like this: "Persona ID is an implementation of the BrowserID protocol."

Of course, nothing changes for sites, we're still providing the same great product and we'll continue to add features as we were planning. Some of those features will have new names under the Persona brand, alongside ID/Sign-in.

Hope you like the new name, and sorry about any confusion during the transition!

Dan

[Melvin Carvalho]

On 23 February 2012 02:23, Dan Mills <thunder-***@public.gmane.org> wrote:

> Hi all,
>
> I wanted to let you know that today we announced Mozilla Persona, a new
> name for the complete identity offering from Mozilla. Read more about it at
> our blog:
>
> http://identity.mozilla.com/post/18038609895/introducing-mozilla-persona
>
>
>
> BrowserID will stay as a technology name, but the consumer-facing brand of
> our service will fall under the Persona brand. You can think about it like
> this: "Persona ID is an implementation of the BrowserID protocol."
>
> Of course, nothing changes for sites, we're still providing the same great
> product and we'll continue to add features as we were planning. Some of
> those features will have new names under the Persona brand, alongside
> ID/Sign-in.
>
> Hope you like the new name, and sorry about any confusion during the
> transition!
>

I welcome this approach.

On your blog it says you are intending to be "Web Scale". It would be
great to drill down into a little detail.

The scale of a system is determined by it's identifier. Local identifiers
scale locally. Global identifier scale globally.

The key consideration here is regarding email addresses. Whether personas
support ONLY email addresses or not, is another debate. It seems to be, at
least at this stage, that only email addresses as identifiers will be
supported. I think that decision is absolutely fine.

However, in order for this to scale some think like a userURI field will
need to be added to the session with the mailto: prefix. This leaves you
as a web scale system architecturally, but as an email specific solution
with respect to the user interaction.

Let me know if that makes sense?



>
> Dan
>
> _______________________________________________
> dev-identity mailing list
> dev-identity-CzyLcWPZiU5YsZ3hbOqMTti2O/***@public.gmane.org
> https://lists.mozilla.org/listinfo/dev-identity
>

[Ben Adida]

On 2/23/12 1:30 AM, Melvin Carvalho wrote:
> However, in order for this to scale some think like a userURI field will
> need to be added to the session with the mailto: prefix. This leaves you
> as a web scale system architecturally, but as an email specific solution
> with respect to the user interaction.

I'm not sure I understand the distinction here. Do you mean that email
addresses are not web scale? Why not?

-Ben

[Peter Williams]

"web scale" to web architects is about lifecycle of the identifiers too, not only their form and provenance. Its not about only the quantity of the datum, its about the ways in which it can be reused in an uncountable number of ways not considered AND NOT CONTROLLED BY the original issuer of the identifier. Something cannot be web scale if its not free to be re-purposed by anyone. Just imagine us looking back at the web if the http URI addressing dynamically-generated document streams had to have been "issued" by an authoritative source. It would have gone as far as the URN. of course, this flies in the face of the typical goal of any security regime around identifers, including branding trust icons such as Persona. Such is the challenge of web scale security. BY leveraging branding theor
y (one of the first lessons VISA taught the fledgling VeriSign on how to run a TTP service), one CAN leap from secure identifiers to branded trust, though. > Date: Thu, 23 Feb 2012 06:36:0
0 -0800
> From: ben-i1dhdUG7r+***@public.gmane.org
> To: dev-identity-CzyLcWPZiU5YsZ3hbOqMTti2O/***@public.gmane.org
> Subject: Re: Announcing Mozilla Persona
>
> On 2/23/12 1:30 AM, Melvin Carvalho wrote:
> > However, in order for this to scale some think like a userURI field will
> > need to be added to the session with the mailto: prefix. This leaves you
> > as a web scale system architecturally, but as an email specific solution
> > with respect to the user interaction.
>
> I'm not sure I understand the distinction here. Do you mean that email
> addresses are not web scale? Why not?
>
> -Ben
> _______________________________________________
> dev-identity mailing list
> dev-identity-CzyLcWPZiU5YsZ3hbOqMTti2O/***@public.gmane.org
> https://lists.mozilla.org/listinfo/dev-identity

[Ben Adida]

On 2/23/12 6:47 AM, Peter Williams wrote:
>
> "web scale" to web architects is about lifecycle of the identifiers
> too, not only their form and provenance. Its not about only the quantity
> of the datum, its about the ways in which it can be reused in an
> uncountable number of ways not considered AND NOT CONTROLLED BY the
> original issuer of the identifier. Something cannot be web scale if its
> not free to be re-purposed by anyone.

And how are URIs not similarly constrained?

http://<domain>/<whatever>

is always controlled by <domain>, isn't it? It basically has the same
lifecycle as <whatever>@<domain>.

-Ben

[Peter Williams]

Thinking is is too syntactic, Ben. The "authority" in an http URI scheme MAY have been intended to be hierachical world, tying the paths to domain names, but this is HARDLY how we use the web. If one locally CNAMES the authority in a local DNS server (or windows file), whatever "hierarchy" of control that flowed from the DNS zone is lost. And the web could not care less that the identifier lost its original roots. It was only ever a reference to start with. yes, http://ibm.com/myspec.html has a copyright control built into it (reasonable use of the IBM brand). And its able to project IBMs trustworthiness (and its engineering prowess). its a good identifier, and one thats trustworthy by semantic brand association - and so is specs-***@public.gmane.org but for it to be "webscale" (a term of art) ***@i
bm.com also has to be available as specs%ibm.com-***@public.gmane.org, or specs%12341234-***@public.gmane.org The identifier has to be intended for endless renaming, repurposing, by parties unknown,
in a system of references who reference points are not well-known and not inhernelty well connected to each other. it has to be messy, and yet survive and prosper. Perhaps the physics analogy helps: measure it, lose it. Or in the web version, control the identifier, lose the web. You can smell a public trust effort by how much it cares about gazillions of low-assurance identifiers, distinguished from private trusts working with a smaller number of higher assurance identifiers. A well known NSTIC architect made a faux-pas the other day, by declaring NSTIC doesnt care about NIST LOA1 identifiers. This means ... it doesnt care about the public trust! If you want folk to opt into a private trust enterprise, first improve their public trust experience (by makign the basic auth uid/password pro
blem go away). having "gained" the public trust (thereby) which will be contingent on not changing web dynamics. In so doing, then some (even national-scale) private communities will opt-in
to more "managed trust". > Date: Thu, 23 Feb 2012 06:50:30 -0800
> From: ben-i1dhdUG7r+***@public.gmane.org
> To: dev-identity-CzyLcWPZiU5YsZ3hbOqMTti2O/***@public.gmane.org
> Subject: Re: Announcing Mozilla Persona
>
> On 2/23/12 6:47 AM, Peter Williams wrote:
> >
> > "web scale" to web architects is about lifecycle of the identifiers
> > too, not only their form and provenance. Its not about only the quantity
> > of the datum, its about the ways in which it can be reused in an
> > uncountable number of ways not considered AND NOT CONTROLLED BY the
> > original issuer of the identifier. Something cannot be web scale if its
> > not free to be re-purposed by anyone.
>
> And how are URIs not similarly constrained?
>
> http://<domain>/<whatever>
>
> is always controlled by <domain>, isn't it? It basically has the same
> lifecycle as <whatever>@<domain>.
>
> -Ben
> _______________________________________________
> dev-identity mailing list
> dev-identity-CzyLcWPZiU5YsZ3hbOqMTti2O/***@public.gmane.org
> https://lists.mozilla.org/listinfo/dev-identity

[Melvin Carvalho]

On 23 February 2012 15:36, Ben Adida <ben-i1dhdUG7r+***@public.gmane.org> wrote:

> On 2/23/12 1:30 AM, Melvin Carvalho wrote:
>
>> However, in order for this to scale some think like a userURI field will
>> need to be added to the session with the mailto: prefix. This leaves you
>> as a web scale system architecturally, but as an email specific solution
>> with respect to the user interaction.
>>
>
> I'm not sure I understand the distinction here. Do you mean that email
> addresses are not web scale? Why not?
>

A fully qualified email address is web scale

e.g.

mailto:user-***@public.gmane.org

the string alone without the URI scheme is not web scale because it is
possible to imagine other identity schemes in future containing the @ sign

Basically adding a scheme allows more flexibility in the long term.

Example one day firefox mobile might allow you to identify with your phone
using the tel: URI scheme etc.


>
> -Ben
>
> ______________________________**_________________
> dev-identity mailing list
> dev-identity-CzyLcWPZiU5YsZ3hbOqMTti2O/***@public.gmane.org
> https://lists.mozilla.org/**listinfo/dev-identity<https://lists.mozilla.org/listinfo/dev-identity>
>

[Ben Adida]

On 2/23/12 7:52 AM, Melvin Carvalho wrote:
>
> A fully qualified email address is web scale
>
> e.g.
>
> mailto:user-***@public.gmane.org <mailto:user-***@public.gmane.org>
>
> the string alone without the URI scheme is not web scale because it is
> possible to imagine other identity schemes in future containing the @ sign

I see your point regarding added flexibility, but I disagree that this
makes email addresses not web scale.

We're open to think about other approaches to identification, e.g. with
your phone number, but before we delve into that, we need to understand
what the trust paths would be. My feeling is that it would be premature
to spec this without understanding those trust paths.

(Specifically, the trust path we have now is that domain.com is
authoritative for *@domain.com.)

-Ben

[Melvin Carvalho]

On 23 February 2012 17:46, Ben Adida <ben-i1dhdUG7r+***@public.gmane.org> wrote:

> On 2/23/12 7:52 AM, Melvin Carvalho wrote:
>
>>
>> A fully qualified email address is web scale
>>
>> e.g.
>>
>> mailto:user-***@public.gmane.org <mailto:user-***@public.gmane.org>
>>
>>
>> the string alone without the URI scheme is not web scale because it is
>> possible to imagine other identity schemes in future containing the @ sign
>>
>
> I see your point regarding added flexibility, but I disagree that this
> makes email addresses not web scale.
>

For example in a browser. Put an email address in an href. If you add the
mailto: prefix your browser will know to open your email client.

With a string only, you have to guess.


>
> We're open to think about other approaches to identification, e.g. with
> your phone number, but before we delve into that, we need to understand
> what the trust paths would be. My feeling is that it would be premature to
> spec this without understanding those trust paths.
>

I'm not suggesting that other identifiers are used, at this point. I am
suggesting that the BrowserID is architected in such as way that it is
flexible enough to handle anything.

BrowserID is email only, and that might be the way BrowserID will always
be. That's fine, but why close doors at this point. Adding a simple field
or prefix is an overhead of just a few characters, and you gives you the
flexibility to move any direction you want, in future.

The bigger win here is the 'universality' ( which i loosely termed web
scale ) which essentially means that different authentication can play
nicely with each other, and developers can use the right tool for the right
job.


>
> (Specifically, the trust path we have now is that domain.com is
> authoritative for *@domain.com.)
>

This makes a lot of sense. As I say there's a difference between the root
architecture of the data, and the interaction that is exposed in the
interface. Perhaps 5-10 years from now there will be an easy way to
authenticate billions of cell phones in the browser. If Browserid is
designed with scale in mind, that can be turned on, at a later date,
without having to rearchitect the whole core.


>
> -Ben
>

[Ben Adida]

On 2/23/12 8:59 AM, Melvin Carvalho wrote:
>
> For example in a browser. Put an email address in an href. If you add
> the mailto: prefix your browser will know to open your email client.

Sure, I understand that. What I'm not sure about is whether a URI is
what we want for users. In particular, we need a mechanism for messaging
users, not just identifying them.

> I'm not suggesting that other identifiers are used, at this point. I am
> suggesting that the BrowserID is architected in such as way that it is
> flexible enough to handle anything.

Gotcha. So in that sense we're already there. The certificates issued by
IdPs look like this:

{
"public-key" : ...
"principal" : {
"email": "ben-i1dhdUG7r+***@public.gmane.org"
}
}

We're not supporting anything other than email yet.

-Ben

[Melvin Carvalho]

On 24 February 2012 05:12, Ben Adida <ben-i1dhdUG7r+***@public.gmane.org> wrote:

> On 2/23/12 8:59 AM, Melvin Carvalho wrote:
>
>>
>> For example in a browser. Put an email address in an href. If you add
>> the mailto: prefix your browser will know to open your email client.
>>
>
> Sure, I understand that. What I'm not sure about is whether a URI is what
> we want for users. In particular, we need a mechanism for messaging users,
> not just identifying them.
>
>
> I'm not suggesting that other identifiers are used, at this point. I am
>> suggesting that the BrowserID is architected in such as way that it is
>> flexible enough to handle anything.
>>
>
> Gotcha. So in that sense we're already there. The certificates issued by
> IdPs look like this:
>
> {
> "public-key" : ...
> "principal" : {
> "email": "ben-i1dhdUG7r+***@public.gmane.org"
> }
> }
>
> We're not supporting anything other than email yet.
>

That's a very good start.

I suppose it means it's just a few lines of code to get the URI from the
data structure.


> -Ben
>

[Peter Williams]

...and that URI can have any scheme, including ldap.



This means we are back to the religion question. Should the scheme resolver for URIs IN THE RP CODE have only "certain" schemes supported?



I can think of some communities that believe that those schemes should be limited to http/s. Others, that it can be ldaps, and webfinger acct...



Now I get the impression that mozilla wants to be a single giant IDP in the cloud, that everyone RP on the planet pings (to verify the signed JWT). If RPs used URI scheme resolvers, this means that the URI and the name in the JWT controls who the endpoint verifier address (and its portocol0 (which is now determined by data = i.e. a control parameters managed by the primary IA) and not by the code library config used by RPs.



its a big step to go to secure name resolvers located from the identifier itself, as sources of validation statements abouts signed JWTs (or any other signed blob). Of course, its a minor variant of OCSP libraries for RPs...that do all the same thing, deciding which source of authority for validation to use (local, or that implied by the X.509 certs AIA field)



Now, Ive never been able to figure if browserid intends, for the email form of the id, for the domain components of the email address to be used to locate the verifier-endpoint for signed JWTs (understanding that mozilla.org might want to set up the location resolver so mozilla runs such web services on behalf of some of those email domains, as a cloud service, much as Google runs openid id message validation services for its million app-domains offering virtual openid IDP endpoints that are actually serviced by Google ).

[Ben Adida]

On 2/24/12 9:19 AM, Peter Williams wrote:
>
> Now I get the impression that mozilla wants to be a single giant IDP
> in the cloud, that everyone RP on the planet pings (to verify the
> signed JWT). If RPs used URI scheme resolvers, this means that the
> URI and the name in the JWT controls who the endpoint verifier
> address (and its portocol0 (which is now determined by data = i.e. a
> control parameters managed by the primary IA) and not by the code
> library config used by RPs.

This is getting a little bit silly. We have explained dozens of time how
we do not plan to be a single giant IdP in the cloud. In fact we spent
months working on the IdP code so that anyone could become an IdP. That
code is live. People are working on standing up their own IdPs.

If you can point to certain things we're doing that actually prevents
folks from becoming IdPs, then please highlight them, we'll be happy to
address them. (Email addresses vs. URIs does not imply that we are the
lone IdP.)

> Now, Ive never been able to figure if browserid intends, for the
> email form of the id, for the domain components of the email address
> to be used to locate the verifier-endpoint for signed JWTs

The verifier endpoint is a convenience. Any RP can run their own.

-Ben

[Peter Williams]

I have half a day today, having finished a joomla SSO plugin (using last decade's techniques, contrasting with signed JSON).



Let me give browserid a go, in that code tree - as an RP.



Hopefully, there are some models around of how to be a good RP, with code performs (a) does self-verification or allows one to run verifier service that other RPs can leverage - starting with my own of course.



I'll start with the latest beta of firefox for windows, and the recently discussed site with a scaffolding that faciliate third party primary IAs.



I think this is the way to test it - by doing it. then... Ive contributed something practical.



The reason I care about third parties doing the validation ... is so that there can be an eco-system of folks adding value to the core act of token validation - augmenting the attributes delivered to the RP site "at the validation stage". This construct is how the old technique of OCSP became a major trust model in its right for some banks, as each bank (on validating a signed message from another bank) would consult its own validation service endpoint - which added somsething about validation procedrues specific to the target bank.



If we can ensure this model takes off, we have a value chain - and a great story. That such a validator might happen to use the mozilla.org-hosted validation service (acting as a proxy to it), is fine. There is then a "chain of" RP-side token-validation services, whose responses about verification "tune up" the user's original token for the needs of the recipient RP site.



This is my goal... and waht motivates my comments here. Its a great story, if one can do it. In another era with different blob formats, it was known as "contextual validation".

[Peter Williams]

I blogged (with appropriate tone) about a few hours with coding tools at http://tinyurl.com/7fuwuqm. Being a blog post, it rambles a bit. But, it does show you how to copy the steps, and repeat them. Id be interesting in some Windows programmer repating the steps, and then taking it a bit further. Where might it go?! In short, I put browserid, delivered entirely by mozilla services, into a chain of security token translation services. This technique is how we, in one part of US realty, keep our web apps insultated from token formats and websso silos. They all have to gateway to Microsoft Azure ACS gateway service, using custom translators we build as required. Assuming this takes off, and the model shown in the post is acceptable to this community, I dont see why this cannot join the openi
d connections we have to Google, Yahoo, and webid world... Its a very loosley coupled integration architecture, intended to keep silo culture and blog/cipher religions at bay - without preve
nting users picking their favorites.
> From: home_pw-***@public.gmane.org
> To: ben-i1dhdUG7r+***@public.gmane.org; dev-identity-CzyLcWPZiU5YsZ3hbOqMTti2O/***@public.gmane.org
> Subject: RE: Announcing Mozilla Persona
> Date: Fri, 24 Feb 2012 11:48:27 -0800
>
>
> I have half a day today, having finished a joomla SSO plugin (using last decade's techniques, contrasting with signed JSON).
>
>
>
> Let me give browserid a go, in that code tree - as an RP.

[Peter Williams]

Do we really need an expliuct URI? Surely one can infer a URI from the token. We could set a convention that its just http://browserid.org/acct/home_pw-***@public.gmane.org, ie. http://{0}/acct/{1} where 0 and 1 come from fields in the (validated) token. They are just issuer and subject.



if one now interprets the webid project as an expression of the linked data world, one URI (and the services attached to it) can now symbolically-link to that URI (that doesnt actually resolve to a stream, using any known protocol). The relying parties sites wanting to build semantic web type sites =then interact with their local linked data repository of URIs, and access services from said repository/space ABOUT the URI thus formed. One then does what the semantic web really wants.. ANY PARTY can overlay its own authority and resolver model onto other links, floating around.



one can have variants, too. The http://browserid.org/acct/home_pw-***@public.gmane.org URI could be made http://browserid.org/acct/home_pw-***@public.gmane.org/12341234123412341234...12341234 where the last field is an md5 (fine for this!) hash of the signature from the token. The linked data repository and its services about such a "manufactured" resource are then, I suppose, making their own statements about the token itself (vs the name in the token).



In the next memo, I going to argue that webid, browserid and openid can all get along fine, and cooperatively, when ONE political thing happens.The US would leap ahead, if it were to happen. The US would have to relinquish a current policy objective though.

[Melvin Carvalho]

On 25 February 2012 18:40, Peter Williams <home_pw-***@public.gmane.org> wrote:

>
> Do we really need an expliuct URI? Surely one can infer a URI from the
> token. We could set a convention that its just
> http://browserid.org/acct/home_pw-***@public.gmane.org, ie. http://{0}/acct/{1} where
> 0 and 1 come from fields in the (validated) token. They are just issuer and
> subject.
>

This is the so-called 'well-known location', similar to webfinger but with
one more hop.

Someone once suggested resolving home_pw-***@public.gmane.org to ->
msn.com/@/home_pw... which is kind of neat.

Setting up a convention is easy. Convincing the whole world to do it is
the hard part. :)

Incidentally read what both eran hammer and mark nottingham said about this
pattern. It's not an ideal solution.


>
>
>
> if one now interprets the webid project as an expression of the linked
> data world, one URI (and the services attached to it) can now
> symbolically-link to that URI (that doesnt actually resolve to a stream,
> using any known protocol). The relying parties sites wanting to build
> semantic web type sites =then interact with their local linked data
> repository of URIs, and access services from said repository/space ABOUT
> the URI thus formed. One then does what the semantic web really wants.. ANY
> PARTY can overlay its own authority and resolver model onto other links,
> floating around.
>

Yes this is the known as a "non information resource". In an open world
assumption you get to choose where you find your claims. This is advanced,
but doable.


>
>
>
> one can have variants, too. The http://browserid.org/acct/home_pw-***@public.gmane.org could be made
> http://browserid.org/acct/home_pw-***@public.gmane.org/12341234123412341234...12341234where the last field is an md5 (fine for this!) hash of the signature from
> the token. The linked data repository and its services about such a
> "manufactured" resource are then, I suppose, making their own statements
> about the token itself (vs the name in the token).
>

Sure


>
>
>
> In the next memo, I going to argue that webid, browserid and openid can
> all get along fine, and cooperatively, when ONE political thing happens.The
> US would leap ahead, if it were to happen. The US would have to relinquish
> a current policy objective though.
>

I already see them all getting along fine. The Web is designed as the
intersection of information spaces. The URI is the identifier and
ultimately unifier. I can translate a local identifier into a URI easily
enough. But the local system gives itself that much more ability to scale
when it does that translation explicitly, rather than, relying on some well
known convention.


> _______________________________________________
> dev-identity mailing list
> dev-identity-CzyLcWPZiU5YsZ3hbOqMTti2O/***@public.gmane.org
> https://lists.mozilla.org/listinfo/dev-identity
>

[Peter Williams]

we know that well known identifier schemes struggle to hit the mark, since they become control points. And every vendor on the planet (and every good-faith government behind them) wants to have last-mile control (keeping the big bucks derived from the direct relationship to a real Person; everyone else in the web being reduced to a factor-role, at diminishing value as a function of distance from and control over the real Person.)



About the only useful thing I learned from my time on the webid project (and FOAF+SSL project before that) was how the web is supposed to work - when there is an absence of control[ling] points (and a release from the economic valuation model). Of course, its a bit academic (since academics/researchers dont have to worry about earning a dollar a service ...from customers.. to pay the bills).



http://linkeddata.uriburner.com/about/html/http/browserid.org/acct/home_pw-***@public.gmane.org is a real resource, about an unknown entity. It even offers translation services - that probably (and hopefully) do little or nothing. But, it does have a web presence. It is a discovery point, that can now be cited. I could now state in my blogspot profile (a vcard entity) that said profile is equivalent (in some sense) to that identified but unknown entity ... and nonsense starts to become value-adding. Of course, anyone can do that.



This is where I see webid and linked data and browserid coming together, with the former elements "adding" some value to the tokens that have been minted, wholly optionally. Of course, not everyone will do it and will certainly not do using the same providers (thats a requirement, so the control/mistrust cycle does not render itself present).



Perhaps some of us remember me (who struggles with advanced ideas) learning how to do http://linkeddata.uriburner.com/about/html/http/rapstr1.blob.core.windows.net/ods/user.ttl%01me. But, mroe than that, we also see something closer to making a page about a token - since it already has a page about a token (albeit an X.509 cert as token).



http://linkeddata.uriburner.com/about/html/data/application/x-x509-user-cert;base64,MIIFHDCCBIWgAwIBAgIKJQnepAAAAAAAIzANBgkqhkiG9w0BAQUFADA2MRMwEQYKCZImiZPyLGQBGRYDY29tMRIwEAYKCZImiZPyLGQBGRYCcHcxCzAJBgNVBAMTAmNhMB4XDTExMTIyMjE2MzExOFoXDTEyMTIyMTE2MzExOFowADCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAuUaSFIlprrGI1U63W4sUeCvbbLQrwyTo6fLhJo1lSoDEoDA3gGftFzCLTkmCsP4PMiU9OAcPWFWgIeJxrVwRUai8BJV31/2C8THm3pxUHUjB3Z1A1MT7E0G1htJveiQuN72oCo4F5r8Q9kT5E7WGJjvqI8n/ijXxfBZd+gNSayUCAwEAAaOCA2UwggNhMDsGCSsGAQQBgjcVBwQuMCwGJCsGAQQBgjcVCP/GWIaLOIWJjSmGuNUphNz9WECH1OFghaezIAIBZwIBBzBfBgNVHSUBAf8EVTBTBgorBgEEAYI3FAICBiUrBgEEAYI3FQj/xliGiziFiY0phrjVKYTc/VhAhO/0JYeF0FYBBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwDgYDVR0PAQH/BAQDAgWgMBYGA1Ud%20IAEB/wQMMAowCAYGBACORgEBMG8GCSsGAQQBgjcVCgEB/wRfMF0wDAYKKwYBBAGCNxQCAjAnB
iUrBgEEAYI3FQj/xliGiziFiY0phrjVKYTc/VhAhO/0JYeF0FYBMAoGCCsGAQUFBwMCMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb
3DQMHMB0GA1UdDgQWBBSdMcIM7BdnzGrx8SSpp9jLU9aFqTCCAWsGA1UdEQEB/wSCAV8wggFbhjhodHRwczovL3JhcHN0cjEuYmxvYi5jb3JlLndpbmRvd3MubmV0L29kcy95b3JrcG9yYy5odG0vI4Y3aHR0cHM6Ly9yYXBzdHIxLmJsb2IuY29yZS53aW5kb3dzLm5ldC9vZHMveW9ya3BvcmMuaHRtI4Y6aHR0cHM6Ly9yYXBzdHIxLmJsb2IuY29yZS53aW5kb3dzLm5ldC9vZHMveW9ya3BvcmMuaHRtLyNtZYY5aHR0cHM6Ly9yYXBzdHIxLmJsb2IuY29yZS53aW5kb3dzLm5ldC9vZHMveW9ya3BvcmMuaHRtI21lhjZodHRwczovL3JhcHN0cjEuYmxvYi5jb3JlLndpbmRvd3MubmV0L29kcy95b3JrcG9yYy5odG2GN2h0dHBzOi8vcmFwc3RyMS5ibG9iLmNvcmUud2luZG93cy5uZXQvb2RzL3lvcmtwb3JjLmh0bS8wHwYDVR0jBBgwFoAUGRUg5dtzBstKNWkCKJwEytiYGZswMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NhLnB3LmNvbS9DZXJ0%20RW5yb2xsL2NhLmNybDANBgkqhkiG9w0BAQUFAAOBgQBHa5SD8Q9jtPKP5R6jUijPAY3BSsMkt7bGkNW+iZklehEBsl+zV7MGMPOsWDknUA3QI6ayoDCD1Wbw2/ibVYfZgZskrJnFNSLzsy5s/OSjmN2CaKhIlTMWVAZ
c3UMK6m1hkCACWEbucU5Fp+tbjaJiE34mDNVWaYyh+6Rk+dICpw== is apparently a "thing" entity, vs the wholly "unknown" entity assigned to my browserid token. And, services can already be delivered ab
out it (not that the the particular linked data site has the slightest relationship to the CA that issued that blob).



Perhaps the test of browserid as a "web technology" is: does it WANT to cooperate with such value adding parties? (using these technologies or others)? Does it EXPECT such parties to add such value (without much coordination)? Does it OBJECT to their existance? do they "dilute the BrowserID brand" (and BrowserID starts issing cease and desist notices to parties "adding value" to its tokens, to keep up its "trustworthiness", as a public brand)? Are such folks like to occup the last mile (access to the protected resources), and does that inherently diminish the value of BrowserID? Is the issue that everyone fears being "dis-intermediated"?





I think its fine for the term "BrowserID" to be a free range hen, whereas Persona is a factory farmed hen - where the free range is more expensive and the factory farmed variant is not only cheaper but its "more controlled" - in a brand protection sense - to preserve a minimal assuranace level. this is just like in the certs world, where anyone can be a CA issuing X.509 certs, but only a network of CAs tied to a given assurance framework (the VeriSign CPS) could claim to be delivering "DigitalIDs" (a trademarked line in the sand, optionally bought into).



So long as BrowserID has a huge free range version, I think "Persona" is fine (and good step in assurance delivery). If such a Persona were to become hijacked and start to market itself as the now-baseline for the public space, than I have no doubt it will feel the full fury of the public backlash. I wonder of mozilla has any institutional history of when the Netscape firm in its browser did NOT allow one to load one's own cert roots (and the backlash that erupted over that!)



I get the impression Mozilla folks, whose culture Im meeting for the first time in 15 years of web work, have their heads set right. They (unlike PayPal, say, over the wikileaks case) do grasp what not to do, in identity management for the public trust.

[Michiel de Jong]

Sounds good! One section wasn't totally clear to me:

"BrowserID remains the developer-facing name of the protocol. Websites,
email providers, and browser implementors will continue to refer to the
BrowserID protocol."

So we as RP developers should still invite our end users to "Sign in with
BrowserID" on our websites, and present the recognizable blue Sign in
button, right? So the term BrowserID will still exist in the minds of an
end-user, to refer to the open web standard? And then when they click, they
will be prompted to pick either a Mozilla Persona, or a Safari Hat, or an
Opera Singer, or whatever other browsers might implement. Correct? I think
it's important to instruct RPs on how to present the Sign in button, so
that the login option on websites is not accidentally presented as the
Mozilla product.

Also, i didn't get whether the centralized fallback of BrowserID (
browserid.org) will also be rebranded or not? Or only the (planned) Firefox
plugin/feature?


cheers!
Michiel

On Thu, Feb 23, 2012 at 1:23 AM, Dan Mills <thunder-***@public.gmane.org> wrote:

> Hi all,
>
> I wanted to let you know that today we announced Mozilla Persona, a new
> name for the complete identity offering from Mozilla. Read more about it at
> our blog:
>
> http://identity.mozilla.com/post/18038609895/introducing-mozilla-persona
>
>
>
> BrowserID will stay as a technology name, but the consumer-facing brand of
> our service will fall under the Persona brand. You can think about it like
> this: "Persona ID is an implementation of the BrowserID protocol."
>
> Of course, nothing changes for sites, we're still providing the same great
> product and we'll continue to add features as we were planning. Some of
> those features will have new names under the Persona brand, alongside
> ID/Sign-in.
>
> Hope you like the new name, and sorry about any confusion during the
> transition!
>
> Dan
>
> _______________________________________________
> dev-identity mailing list
> dev-identity-CzyLcWPZiU5YsZ3hbOqMTti2O/***@public.gmane.org
> https://lists.mozilla.org/listinfo/dev-identity
>

[d***@public.gmane.org]

On 23 Feb 2012, at 10:15, Michiel de Jong wrote:

> Sounds good! One section wasn't totally clear to me:
>
> "BrowserID remains the developer-facing name of the protocol. Websites,
> email providers, and browser implementors will continue to refer to the
> BrowserID protocol."
>
> So we as RP developers should still invite our end users to "Sign in with
> BrowserID" on our websites, and present the recognizable blue Sign in
> button, right? So the term BrowserID will still exist in the minds of an
> end-user, to refer to the open web standard? And then when they click, they
> will be prompted to pick either a Mozilla Persona, or a Safari Hat, or an
> Opera Singer, or whatever other browsers might implement. Correct? I think
> it's important to instruct RPs on how to present the Sign in button, so
> that the login option on websites is not accidentally presented as the
> Mozilla product.
>
> Also, i didn't get whether the centralized fallback of BrowserID (
> browserid.org) will also be rebranded or not? Or only the (planned) Firefox
> plugin/feature?
>


+1 I'm glad the rebranding is progressing, but I'd really like to see a rundown of what's going to be available at what URL/domain and what you expect to be putting in the native UI. Explaining that someone's 'Mozilla Persona' is provided by their e-mail provider sounds odd, so I assume that's not how you're thinking about this?

Congrats on the new name!
David

[Peter Williams]

Lets recall (as billed) use of remoted-APIs for minting JTWs and mozilla (us)-hosted services for verifying signed JWTs and optionally affioxed JWC-objects (non-X.509 certs from "primary" "Issuing Providers") is a "bootstrap". It exists in parallel with other incarnations of the same flow, in which Mozilla"Site" web services may play NO part (either becuase someone else does the equivalent functions (e.g. the UK incarnation of Mozilla or a competitor), or both browser and RP site are "native" (and 100% self-contained).



If a RP site wants to use these various means of processing the signed JWTs, presumably it will have a variety of icons.



1. It might say: Mozilla Persona accepted here.



2. It might say: Peter (UK) Persona accepted here (when PeterSite (UK) competes with MozillaSites (UK) (US) in remote JWT minting/verifying)



3 If the RP accept JWTs minted by a native-BRowserID-enabled-Browser (and validates the JWT all by itself), it might only say BrowserID(s) accepted here.



have I got the RP-side branding distinctions - for who or what is involved in which capacity - about right?

[Matjaz Horvat]

I'd like to second these questions by Michiel and David in the name of
localizers, would like to see https://browserid.org/about fully localized.

If I understand correctly, BrowserID will be renamed to Persona ID soon (
personaid.org has already been registered by Mozilla)?

Best,
Matjaž

On Thu, Feb 23, 2012 at 8:33 PM, <***@gmail.com> wrote:

>
> On 23 Feb 2012, at 10:15, Michiel de Jong wrote:
>
> > Sounds good! One section wasn't totally clear to me:
> >
> > "BrowserID remains the developer-facing name of the protocol. Websites,
> > email providers, and browser implementors will continue to refer to the
> > BrowserID protocol."
> >
> > So we as RP developers should still invite our end users to "Sign in with
> > BrowserID" on our websites, and present the recognizable blue Sign in
> > button, right? So the term BrowserID will still exist in the minds of an
> > end-user, to refer to the open web standard? And then when they click,
> they
> > will be prompted to pick either a Mozilla Persona, or a Safari Hat, or an
> > Opera Singer, or whatever other browsers might implement. Correct? I
> think
> > it's important to instruct RPs on how to present the Sign in button, so
> > that the login option on websites is not accidentally presented as the
> > Mozilla product.
> >
> > Also, i didn't get whether the centralized fallback of BrowserID (
> > browserid.org) will also be rebranded or not? Or only the (planned)
> Firefox
> > plugin/feature?
> >
>
>
> +1 I'm glad the rebranding is progressing, but I'd really like to see a
> rundown of what's going to be available at what URL/domain and what you
> expect to be putting in the native UI. Explaining that someone's 'Mozilla
> Persona' is provided by their e-mail provider sounds odd, so I assume
> that's not how you're thinking about this?
>
> Congrats on the new name!
> David
>
> _______________________________________________
> dev-identity mailing list
> dev-***@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
>

[Melvin Carvalho]

On 23 February 2012 02:23, Dan Mills <thunder-***@public.gmane.org> wrote:

> Hi all,
>
> I wanted to let you know that today we announced Mozilla Persona, a new
> name for the complete identity offering from Mozilla. Read more about it at
> our blog:
>
> http://identity.mozilla.com/post/18038609895/introducing-mozilla-persona
>

Forgot to mention. On the subject of persona's this is worth looking at.

http://wiki.eclipse.org/Persona_Data_Model_2.0#Vocabularies

It should be reasonably possible to link a browser id (currently email) to
other items. I'm guessing JSON is going to be the path of least
resistance.


>
>
> BrowserID will stay as a technology name, but the consumer-facing brand of
> our service will fall under the Persona brand. You can think about it like
> this: "Persona ID is an implementation of the BrowserID protocol."
>
> Of course, nothing changes for sites, we're still providing the same great
> product and we'll continue to add features as we were planning. Some of
> those features will have new names under the Persona brand, alongside
> ID/Sign-in.
>
> Hope you like the new name, and sorry about any confusion during the
> transition!
>
> Dan
>
> _______________________________________________
> dev-identity mailing list
> dev-identity-CzyLcWPZiU5YsZ3hbOqMTti2O/***@public.gmane.org
> https://lists.mozilla.org/listinfo/dev-identity
>

[Peter Williams]

Higgins model Looks good - but does it solve the problem?

I'm not seeing any of the schemes learn from what didn't work about digitalds (when offloading session mgt to a proxy's ssl sessionids cache, for device independence - yada yada ).

I'm seeing wonderful finessing on several fronts of 10% of the issue set (on boarding, distributing work over the usual agents, modeling the topology of endpoints dynamically, ...).

I like browserid (comparing it to cardspace). But the art of this space st web scale is in the management and control planes, not only the ux. separating apps from member data and offloading app session mgt to third parties interferes with fundamental business economics of a service-factor market (think travel agents, eliminated by the Internet).

Mozilla hopefully know at what speed to introduce economic threats due to the disruptive nature of this topic, and not go too fast. One may wish not, yes not, bundle privacy policy management (for 5years); or governance methods over sp sites. One may wish to just solve the password problem ... And do so without disrupting too many things at once (inducing mistrust as core fears are exposed about loss of control).

Sent from my iPhone

On Feb 27, 2012, at 12:04 PM, "Melvin Carvalho" <melvincarvalho-***@public.gmane.org> wrote:

> On 23 February 2012 02:23, Dan Mills <thunder-***@public.gmane.org> wrote:
>
>> Hi all,
>>
>> I wanted to let you know that today we announced Mozilla Persona, a new
>> name for the complete identity offering from Mozilla. Read more about it at
>> our blog:
>>
>> http://identity.mozilla.com/post/18038609895/introducing-mozilla-persona
>>
>
> Forgot to mention. On the subject of persona's this is worth looking at.
>
> http://wiki.eclipse.org/Persona_Data_Model_2.0#Vocabularies
>
> It should be reasonably possible to link a browser id (currently email) to
> other items. I'm guessing JSON is going to be the path of least
> resistance.
>
>
>>
>>
>> BrowserID will stay as a technology name, but the consumer-facing brand of
>> our service will fall under the Persona brand. You can think about it like
>> this: "Persona ID is an implementation of the BrowserID protocol."
>>
>> Of course, nothing changes for sites, we're still providing the same great
>> product and we'll continue to add features as we were planning. Some of
>> those features will have new names under the Persona brand, alongside
>> ID/Sign-in.
>>
>> Hope you like the new name, and sorry about any confusion during the
>> transition!
>>
>> Dan
>>
>> _______________________________________________
>> dev-identity mailing list
>> dev-identity-CzyLcWPZiU5YsZ3hbOqMTti2O/***@public.gmane.org
>> https://lists.mozilla.org/listinfo/dev-identity
>>
> _______________________________________________
> dev-identity mailing list
> dev-identity-CzyLcWPZiU5YsZ3hbOqMTti2O/***@public.gmane.org
> https://lists.mozilla.org/listinfo/dev-identity

[Melvin Carvalho]

On 27 February 2012 23:38, Peter Williams <home_pw-***@public.gmane.org> wrote:

> Higgins model Looks good - but does it solve the problem?
>

The page is a (pretty comprehensive) collection of existing techniques for
establishing richer information from an ID.

For example, from an email address you can get a Name etc. but the concept
is very extensible ...


>
> I'm not seeing any of the schemes learn from what didn't work about
> digitalds (when offloading session mgt to a proxy's ssl sessionids cache,
> for device independence - yada yada ).
>
> I'm seeing wonderful finessing on several fronts of 10% of the issue set
> (on boarding, distributing work over the usual agents, modeling the
> topology of endpoints dynamically, ...).
>
> I like browserid (comparing it to cardspace). But the art of this space st
> web scale is in the management and control planes, not only the ux.
> separating apps from member data and offloading app session mgt to third
> parties interferes with fundamental business economics of a service-factor
> market (think travel agents, eliminated by the Internet).
>
> Mozilla hopefully know at what speed to introduce economic threats due to
> the disruptive nature of this topic, and not go too fast. One may wish not,
> yes not, bundle privacy policy management (for 5years); or governance
> methods over sp sites. One may wish to just solve the password problem ...
> And do so without disrupting too many things at once (inducing mistrust as
> core fears are exposed about loss of control).
>
> Sent from my iPhone
>
> On Feb 27, 2012, at 12:04 PM, "Melvin Carvalho" <melvincarvalho-***@public.gmane.org>
> wrote:
>
> > On 23 February 2012 02:23, Dan Mills <thunder-***@public.gmane.org> wrote:
> >
> >> Hi all,
> >>
> >> I wanted to let you know that today we announced Mozilla Persona, a new
> >> name for the complete identity offering from Mozilla. Read more about
> it at
> >> our blog:
> >>
> >>
> http://identity.mozilla.com/post/18038609895/introducing-mozilla-persona
> >>
> >
> > Forgot to mention. On the subject of persona's this is worth looking at.
> >
> > http://wiki.eclipse.org/Persona_Data_Model_2.0#Vocabularies
> >
> > It should be reasonably possible to link a browser id (currently email)
> to
> > other items. I'm guessing JSON is going to be the path of least
> > resistance.
> >
> >
> >>
> >>
> >> BrowserID will stay as a technology name, but the consumer-facing brand
> of
> >> our service will fall under the Persona brand. You can think about it
> like
> >> this: "Persona ID is an implementation of the BrowserID protocol."
> >>
> >> Of course, nothing changes for sites, we're still providing the same
> great
> >> product and we'll continue to add features as we were planning. Some of
> >> those features will have new names under the Persona brand, alongside
> >> ID/Sign-in.
> >>
> >> Hope you like the new name, and sorry about any confusion during the
> >> transition!
> >>
> >> Dan
> >>
> >> _______________________________________________
> >> dev-identity mailing list
> >> dev-identity-CzyLcWPZiU5YsZ3hbOqMTti2O/***@public.gmane.org
> >> https://lists.mozilla.org/listinfo/dev-identity
> >>
> > _______________________________________________
> > dev-identity mailing list
> > dev-identity-CzyLcWPZiU5YsZ3hbOqMTti2O/***@public.gmane.org
> > https://lists.mozilla.org/listinfo/dev-identity
> _______________________________________________
> dev-identity mailing list
> dev-identity-CzyLcWPZiU5YsZ3hbOqMTti2O/***@public.gmane.org
> https://lists.mozilla.org/listinfo/dev-identity
>