Add the token back as an optional argument that is fetched dynamically.

[bvandersloot-mozilla]

Aiming to resolve #42

[bvandersloot-mozilla]

@ekovac: does this make sense in the context of the discussion on #42?

[ekovac]

If the tokenURL has to be supplied by the RP, that feels like an arbitrary difference vs "full" FedCM. Is there any reason we don't want to just use the existing configURL mechanism?

[bvandersloot-mozilla]

I considered using the whole configURL mechanism. The biggest piece is that we don't need the protections offered by the .well-known resource's redirection, since this request is sent after the credential is chosen. Then it makes sense to me to make it as easy to use as possible, which is just another Javascript parameter. The well-known is still part of the opt-in path to FedCM, and the endpoint can stay the same.

I realized while writing this that a better place to put this is in the IDP's store, which is more equivalent to the configURL. Change made.

[TallTed]

Human-facing, should be editorial.

[samuelgoto]

Is tokenUrl the same as the id_assertion_endpoint?

[bvandersloot-mozilla]

Exactly! Maybe it would be better to rename it to idAssertionURL?

[samuelgoto]

It is a little ugly, but I think conceptually right :)