mozilla / id-specs Goto Github PK

hi,

I wads reading the spec and all the doc about browserid; I find it great but I was wondering why did you chose the simple domain name for hosting the IDP.

it is clear that [email protected] should be provided by example.com but I was wondering why it could not be id.example.com.

In my mind, this would simplify deploying IDP software aside another service hosted at example.com

I was just wondering what could be the implications of my suggestion :-)

thanks!

Now that beta1 shipped, I don't think we should have a delta between beta1 and prod.

when loggedInEmail is non-null but doesn't match what the identity module believes it should be. And then when the new identity can't be provisioned.

Hi,

I'm trying to get my own identity provider work. In the mean time I was thinking about using the default login.persona.org IdP with my email address.

From what I've read, once I make my IdP work, all persona enabled websites will automatically use my IdP instead of the default one. Is it true?

Thanks for the help :)

The section describing the format of a "BrowserID Support Document" says that is must contain fields named "jwk", "authentication", and "provisioning". The example document has fields named "publicKeys", "authentication" and "provisioning".

Both the dev and prod versions of browserid/index.md do not appear to actually ever explain what JWT is. It would be probably be useful to link to the relevant spec (and expand the initialism at first mention); it appears to be JSON Web Token?

Currently, the spec defers to JWT for expiry / etc times; that spec defines them to be IntDate, which is seconds from epoch. However, the current implementations appear to assume it's call milliseconds-from-epoch (passing it directly to the JavaScript Date constructor).

Please either change the spec to say milliseconds (deviating from JWT) or change the implementations to use seconds :)

It was brought up before and I don't have strong feelings either way but I haven't heard of clear decision.

ie. the object passed to watch has a "loggedInEmail" property.

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please reach out to [email protected].

(Message COC001)

Should these be in the identity spec?

They're live in production...

Requiring an A/AAAA record on the root of a idenity-providing domain is unacceptable. This could be worked around with browsers supporting SRV records, but that's probably never going to happen.

From my reading of http://openid.net/specs/draft-jones-json-web-token-07.html , the sample JWTs in browserid/index.md should have a "typ" header field in addition to the cited "alg" one, so:

{"typ": "JWT", "alg": "RS256"}

instead of:

{"alg": "RS256"}

am I reading this right? If so, I'll whip up a patch for the docs.

Currently, the Persona login screen and BrowserID protocol assumes the user will authenticate an identity which is exactly the one which they have typed in to the 'Email' field.

We want to make dynamic identifiers (and thus Identities) possible.

Use Cases:

• Opaque Identifiers - Our BlueVia IdP will not have any user input and will generate an opaque id for each user
• Pseudonymity - An IdP that with a stable user ID which authenticates as other pseudonyms.
• Spam avoidance - [email protected]

Proposed changes to the spec:

Update beginAuthentication to indicate that email is a hint and not a hard requirement. Email may actually be null.
It's up to the IdP's discretion on how to authenticate the user as controlling an identity or identities.

navigator.id.beginAuthentication(function(email) {
       // email may be null
       // but lets assume email is [email protected]
});

Update completeAuthentication to take a dictionary with id as the actual identifier chosen for the current user.

Also, an IdP can indicate that certain dynamic identities shouldn't show up in the email picker.

navigator.id.completeAuthentication({
        “id”: "[email protected]"
});

If the dynamic identifier ([email protected] in this case) is not SMTP routable, it should indicate this in the certificate it issues to the user.

{
  “principal”: {“email”: “...”, “protocol”: null}
}

An RP can request an identity from an IdP by using requireDomain instead of the more specific requireEmail in navigator.id.request or navigator.id.watch.

Like is mentioned at https://developer.mozilla.org/en%2FBrowserID%2FSpecify+an+Email+Address

It seems like this scenario isn't supported right now: say my email address [email protected] in fact forwards to [email protected]. It would be great if I can setup a support document on example.com to make the IdP for gmail.com (in this case, BigTent?) handle identification for [email protected].

IIRC this is something that works with OpenID.

All JWT drafts so far have stated than an IntDate (the value for the exp and iat keys) should be in seconds since the epoch. The BrowserID (beta1) spec says it's ms since the epoch. This should be corrected; there should probably be a compatibility fix in the verifier.

The fallback IdP is mentioned a few times, and properly defined. However, there's also a reference to "Fallback Mode", which isn't properly defined at all.

For IDP Auth, there are references to both raiseAuthenticationFailure and cancelAuthentication for the same purpose. It seems like one replaced the other so all references to the old name should be updated.

In the following paragraph:

Declaring Support and Parameters for BrowserID

To declare support for BrowserID, a domain MUST publish either a BrowserID support document OR a BrowserID
delegated-support document at a specific URI relative to the domain's SSL URI. The relative reference URI for this
document is /.well-known/browserid, as per RFC5785. The domain MAY choose to reference this BrowserID support
document from a host-meta file (as per RFC5785)."

The string 'host-meta file' is nowhere in RFC5785.

Clarifying precisely what you mean would be helpful.

ie.
onlogin => onLogin
onlogout => onLogout

to be more consistent with other DOM APIs

FYI: The following changes were made to this repository's wiki:

• defacing spam has been removed

• the wiki has been disabled, as it was not used

These were made as the result of a recent automated defacement of publically writeable wikis.