FIDO2 Server API - how to context?

[Philipp Junghannß]

for both the result endpoint there does not seem to be any context given to the requested options set.

https://github.com/fido-alliance/conformance-test-tools-resources/blob/master/docs/FIDO2/Server/Conformance-Test-API.md#example-authenticator-attestation-response

https://github.com/fido-alliance/conformance-test-tools-resources/blob/master/docs/FIDO2/Server/Conformance-Test-API.md#authentication-example-authenticator-assertion-response

How exactly is the server supposed to know which request this response is for? just trying against all currently running requests, I doubt that, or does this API get its requests with cookies? then I could use those to store stuff (e.g. in a PHP session).

Regards

[Dani Mező]

Hi Philipp,

Well, these result endpoints suppose to have different paths, one is attestation/result, the other is assertion/result, for registation and authentication respectively. This should be good enough for the server to be able to distinguish between them.

This question however is valid for the options endpoint, where for both ceremonies share the same path, as is suggested in the Conformance API you linked. In that case what we did in our server implementation is to look at the payload: for the creation options request contains a displayName, while the get option request does not. If there are other ways to distinguish, I'd be curious to learn them.

Cheers,

Daniel

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNrqvUrLvT_SCTDUWox2KjqPzq-_9LU4B_qY0xDe9GpYeg%40mail.gmail.com.

[Dani Mező]

Oh I think I misunderstood you.

So the question is how the server can identify the two requests in a ceremony (1. options request + 2. the result submittal) that belongs together right?

Yeah, a cookie would do, or alternatively, you can create a session for the client in the options request, and then find this session upon the results are submitted, based on the challenge that is contained in both the options request and the assertion / attestation.

Cheers, Daniel

[Philipp Junghannß]

that's not what I meant, rather it's like if multiple users are trying to login at the same time how do I makebind each /result request to the preceding /options request (e.g. associating challenge and all)

if multiple users try to register at a similar timeframe, one needs to pin down who's who and not mix up the requests.

if there are for example 3 attestation/options requests open how to associate the results call to them.

[Dani Mező]

Yes, I realized my misunderstanding in my 2nd email. So you can indeed use a cookie for that, or you can associate the two request with the challenge, as it is unique and it is contained in both of them.

[Ackermann Yuriy]

Yes, we use cookies for session 

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAKxP%3DD4B-%2Br8%3DfB-16h92QqD2_FDH3ouVX_DDH4AtU0pGWC%3DTQ%40mail.gmail.com.

--

Yuriy Ackermann

FIDO, Identity, Standards

skype: ackermann.yuriy

github: @herrjemand

twitter: @herrjemand

medium: @herrjemand