Add android platform package about flutter-passkeys HOT 8 CLOSED

One other question: Why are we using a rather "untyped" interface so far? RegisterResponse register(String options)

That means that on boths sides (Android and Flutter) we are not really able to validate much without parsing first because all there is, is a JSON string. We could just use types instead of the string, right?

I used a single json string because the android credential manager just takes the whole json as input - like navigator.create in the browser does, but if it is the better option I'll create the json in native code instead of flutter. However ideally you would use the raw pubKey-jsonobject that's coming from the backend without having to parse it, change it and encode it back to a string (except for validation maybe) - maybe I'll find a clean way to do that

Edit: Stayed with parsing and added variables to pass down for the important additional parameters

from flutter-passkeys.

Yes sure makes sense, I called it getFacetID because that's what the spec names it. If origin is a better name, I can change it to that.

from flutter-passkeys.

@nicolaistein quick question regarding the "Origin" header:
I saw that you added android:apk-key-hash:xyz as an "Origin" header.
Is our frontend API already respecting that header? I did not set it for the iOS implementation and I still got valid responses. Did you have problems when not setting it?

from flutter-passkeys.

One other question: Why are we using a rather "untyped" interface so far?
RegisterResponse register(String options)

That means that on boths sides (Android and Flutter) we are not really able to validate much without parsing first because all there is, is a JSON string. We could just use types instead of the string, right?

from flutter-passkeys.

@nicolaistein quick question regarding the "Origin" header: I saw that you added android:apk-key-hash:xyz as an "Origin" header. Is our frontend API already respecting that header? I did not set it for the iOS implementation and I still got valid responses. Did you have problems when not setting it?

Android puts the apk key hash as origin in the signed clientDataJSON and our api requires the clientDataJSON-origin to be identical to the origin of the webauthn api requests
ios doesn't do that so no origin change in the requests is required.

from flutter-passkeys.

@nicolaistein quick question regarding the "Origin" header: I saw that you added android:apk-key-hash:xyz as an "Origin" header. Is our frontend API already respecting that header? I did not set it for the iOS implementation and I still got valid responses. Did you have problems when not setting it?

Android puts the apk key hash as origin in the signed clientDataJSON and our api requires the clientDataJSON-origin to be identical to the origin of the webauthn api requests ios doesn't do that so no origin change in the requests is required.

Ok I see, makes sense. Two things we can think about:

• I am not perfectly familiar with the WebAuth0 specs, but I would guess that iOS does something similar than Android here. At least there are some FIDO docs that explain that: https://fidoalliance.org/specs/uaf-v1.0-id-20141122/fido-appid-and-facets-v1.0-id-20141122.html#the-appid-and-facetid-assertions => if that is true, we might have to do something for iOS here (+ mabye also our backend misses something)
• "getSignatureFingerprint" (the method that we added in this issue) is very Android specific. If it turns out that iOS also sends an Origin header we could change that to a method like "getOriginHeader" => than every platform can make its own decision on the header and we don't have to have an unimplemented method in iOS

Does that make sense?

from flutter-passkeys.

Looks good. I had one small comment on the second PR. Besides of that please merge both PRs then.

from flutter-passkeys.

@nicolaistein the PRs are already merged, right? So we can close this issue?

from flutter-passkeys.