[freaky friday] assertion verification gone wild

Lloyd Hilaiel lhilaiel at mozilla.com
Mon Nov 25 13:51:57 PST 2013


On Nov 25, 2013, at 9:20 AM, Ryan Kelly <rfkelly at mozilla.com> wrote:
> 
> I do wonder if it will ever be used with more than one secondary in
> practice.  For example, discussion about whether identity-attached
> services should trust both persona.org and accounts.firefox.com as
> secondaries:
> 
> 
> https://github.com/mozilla/fxa-auth-server/issues/292#issuecomment-28614619
> 
> But it seems right to make that a policy question rather than a
> technical one.

Strongly agree. I think we can identify a minimal set of features that let us deal with final policy decisions in configuration, without having to write any more code.

>> I did *not* get to the final bit, which is to actually build a server around the library that conforms to the existing REST api of our verifier.
> 
> Is the output object from your library essentially what will be output
> by the verifier API?  So the top-level keys would be "email",
> "idpClaims", "rpClaims", etc?

I’m unclear about this.  In order to replace the persona verifier we are constrained in that we would need to be backwards compatible.  My hope was that the verifier would be a very thin layer on top of the library that does all them servery things.

If we are unhappy with the API constraints imposed by back-compat, we could always introduce a v2 REST endpoint with much more stringent rules about how you contact it [1], that returns an improved format.

lloyd

[1] For historical reasons, the current verifier will eat almost anything you throw at it.  json, x-url-encoded form data, GET data.  it’s nutso.

>  Cheers,
> 
>    Ryan
> 




More information about the Dev-fxacct mailing list