[freaky friday] assertion verification gone wild
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
> 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 , that returns an improved format.
 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.
More information about the Dev-fxacct