Re: [FIDO-DEV] Digest for fido-dev@fidoalliance.org - 11 updates in 5 topics
38 views
Skip to first unread message
Perla nallely Guadalupe Alejandre Ramón
Nov 21, 2022, 6:52:49 AM11/21/22
to FIDO Dev (fido-dev)
Buen día disculpe pero no les estoy infringiendo nada el estado de cuenta está a nombre de Jane mi nombre es perla Nallely Guadalupe Alejandre Ramón en city Banamex el nombre es de Karen y en banjico el nombre es de Daniela hasta hoy no me an confirmado si puedo disponer de mi dinero mi teléfono ya no me sirve para poder subir los videos necesito un teléfono que funcione si quiero realizar alguna compra en las aplicaciones que tengo no puedo pues Google sigue haciendo de las suyas y no me ha confirmado ninguna autoridad que puedo disponer de mi dinero donación les ise y fue la misma cantidad que tenía mi cuenta aún así me isieron 17 auditorías y dónde está ese dinero quien se lo quedó además cada vez que me hacen una auditoría me refleja menos dinero y no es mal ávido acceso a sus exigencias y ustedes siguen en lo mismo yo sin poder disponer de lo mío pero agamos un trato ya que no puedo disponer de lo mío y mal que bien estoy cumpliendo con el trato ustedes manden el teléfono y les subo sus videos porque un trato de palabras vale más que cualquier cosa y si se trata de cobrar también empezaré a cobrar igual que ustedes lo justo no tiene vuelta de mi dinero compren el teléfono y lo envían un favor las personas que sigan los videos que suba y jueguen woombal porfavor pagueles de la manera más atenta se los pido
El sáb., 19 de noviembre de 2022 4:59 p. m., <fido...@fidoalliance.org> escribió:
- FW: Alert: Notice of Copyright Infringement - 2 Updates
- Native Apps: OAuth 2 + Native FIDO2: Best practices? - 2 Updates
- Detecting cross device authentication - 1 Update
- Using WebAuthn-created keys from Android App? - 1 Update
- UserHandle Missing at Auth Finish using Android Passkey on Mac Ventura Safari - 5 Updates
Ki-Eun Shin <shin...@gmail.com>: Nov 18 11:30PM -0800
For the second use cases, you can get access token with the refresh token
without a user interaction like the conventional flow.
Do you want to authorize or authenticate again when the user visits again?
If you are a RP side, there are two ways to leverage this.
First approach is that register and use passkey credentials for your own
site and app regardless of OAuth2 provider.
1. Providing your own authentication mechanism (passkeys) with OAuth2. E.g,
after OAuth authorization (or onboarding process), you provide the way for
users to register passkeys on your site (your domain, RP id, and your app).
-> Meaning is that generated credential is only bound to your site and
app. (not to a OAuth2 provider)
2. Then, if the user visits your app or site again, if they need to
re-authenticate, then trigger passkey authentication in your site or app
(You don't need to redirect to the Idp.) This is not related to Oauth2
refersh or access token.
Just leverage authentication mechanisms provided by OAuth2 provider, if
they provide passkey authentication, then you can leverage as it was.
1. If OAuth2 provider offers passkeys somehow, user might register the
passkey in somewhere.
2. When, the explicit authorization or authentication is needed on OAuth2
provider, as you mentioned, perform PKCE flow. Then, the OAuth2 provider
triggers passkey authentication if they provide.
On Friday, November 18, 2022 at 11:32:07 PM UTC+9
Arshad Noor <arsha...@strongkey.com>: Nov 19 06:05AM -0800
Hi Lukas,
Your question reminded me of a conundrum I have little understood. In
light of what FIDO brings to the authentication space, I am going to try
to challenge you (and others) to question your premise around "single
sign-on" (SSO) technology. The goal is not to put anyone on the
defensive about any specific SSO technology, but to debate whether SSO
is even necessary in light of what FIDO offers.
You have to step back into the late '80s and early '90s to understand
why SSO was really needed. Enterprises had a mish-mash of technology
solutions: mainframes running SNA LU6.2, mini-computers with DECNet and
other proprietary protocols, Netware LANs, a smattering of UNIX systems
running TCP/IP, and OS/2 with LAN Manager, etc. Everybody was using
usernames and passwords. And, everybody had different schemes,
algorithms, and protocols for dealing with them. The complexity of
managing this was daunting enough that companies were investing serious
money to solve this problem.
As networks were starting to coalesce around TCP/IP and public-key
cryptography made a splash, for a while in the late '90s, it seemed that
the password problem could be eclipsed by that original passwordless
authentication protocol - SSL ClientAuth - with X.509 v3 digital
certificates. But, that bubble broke with the dot-com crash; and
passwords that were restricted primarily to enterprise networks at the
dawn of the internet, exploded to affect every consumer that needed to
authenticate to a restricted website. Leading us to where we are today:
a mish-mash of SSO protocols and schemes.
FIDO is, essentially, a reboot. An advanced authentication technology that:
* Does NOT <https://dl.acm.org/doi/10.1145/1373290.1373293> depend on
"shared secret authentication";
* Is designed to protect the privacy of consumers;
* Can optionally leverage simple to sophisticated "user verification"
schemes;
* Eliminates <https://fc16.ifca.ai/preproceedings/25_Lang.pdf>
password phishing attacks;
* Is supported on every modern client computing device (many with
secure elements);
* Is supported on every modern browser; and
* Most importantly, is simple enough that it can strongly authenticate
users with the touch of a button.
If a FIDO server can authoritatively return an authentication token in a
few seconds to any web/mobile application, why burden the application
with a legacy SSO protocol that adds yet another "band-aid" to what was
already a band-aid from the previous century? Why not cut the crap in
the middle and just get an authoritative answer from the source?
SSO tokens - whether they are SAML, JWT, etc. - must be verified
thoroughly because they represent a "man in the middle" of the
authentication flow; why introduce or maintain a man in the middle when
the protocol was designd for privacy. Why add the legal burden of
determining who is responsible for privacy violations when the MITM is
breached?
Ah! The answer is "legacy applications". SSO was written into
applications in an age when passwords ruled the world and companies
needed to alleviate the burden of users who were forced to authenticate
to dozens of systems within the enterprise. The cost of SSO was less
than the loss of productivity and consumer frustration with password
management that SSO is accepted as a defacto standard. But, when
passwords have been eliminated and strong authentication has been
simplified, does it make sense to continue carrying that cost of SSO?
The technical compexity? And, the legal burden in a world that is
increasingly regulating privacy? (Note that similar questions arise when
considering the issue
<https://github.com/fido-alliance/common-specs/issues/228> raised with
passkeys held by platform vendors).
It may be useful to step back and ponder whether it may actually benefit
the internet to eliminate the SSO burden - and its associated risks -
when an application can get an authoritative answer from a FIDO server
directly with the simple touch of a button, faster than we can verify
the authenticity and integrity of an SSO token.
Arshad Noor
StrongKey
On 11/18/22 6:32 AM, Lukas Westermann wrote:
Ki-Eun Shin <shin...@gmail.com>: Nov 18 11:50PM -0800
With the Safari on macOS and Android passkey (play service beta), Safari
returns authenticatorAttachment as "Platform". So, with current
implementation, we cannot guide the user to register the passkey on their
device (in this example., macOS). I think this is the bug or intention from
Apple.
On Friday, November 18, 2022 at 5:46:14 PM UTC+9 Shane Weeden wrote:
Ki-Eun Shin <shin...@gmail.com>: Nov 18 11:39PM -0800
It's a kind of cross referencing between the app and web site.
The web (RP id) site should serve asset links (assetlinks.json) including
your native apps information (app's signing certificate fingerprint).
Also, the Android app (which is associated with the site - given RP id)
needs to include such statement.
So, you need to do this cross referencing on your web sit and app.
This is android digital asset links mechanism. Please refer this site:
https://developers.google.com/digital-asset-links/v1/getting-started
In similar way, for iOS native app, it need to do similar job,
app-site-association in Apple ecosystem terms.
On Saturday, November 19, 2022 at 4:24:18 AM UTC+9 Shane Weeden wrote:
Tommy Chu <tomm...@link.money>: Nov 18 04:24PM -0800
Hello everyone.
I am trying to develop Passwordless Login solution using WebAuthn
standards..
Wondering if I could have your expert advise on one issue that has stalled
me over few days already?
Reproducible Environment:
- Authenticator: Android Passkey using QR code
- Browser: Mac Ventura OS Safari
- Server Dependency: Yubico: webauthn-server-core : 2.1.0
1. I am able to see that Server is providing UserHandle(as user.id) to
Client and client uses this information to finish registration process.
2. When Client returns request for Authentication Finish process:
UserHandle is returned empty. This only happens when Authenticating through
Safari with Passkey using Android device.
3. I am passing User Verification to be `Required`.
Wondering if anyone is facing similar issue with this?
Thanks,
Tommy
Shane Weeden <shane....@gmail.com>: Nov 19 10:51AM +1000
Did your call to navigator.credentials.get include a populated allowCredentials list?
Sent from my iPhone
On 19 Nov 2022, at 10:24 am, 'Tommy Chu' via FIDO Dev (fido-dev) <fido...@fidoalliance.org> wrote:
Hello everyone.
I am trying to develop Passwordless Login solution using WebAuthn standards..
Wondering if I could have your expert advise on one issue that has stalled me over few days already?
Reproducible Environment:
Authenticator: Android Passkey using QR code
Browser: Mac Ventura OS Safari
Server Dependency: Yubico: webauthn-server-core : 2.1.0
1. I am able to see that Server is providing UserHandle(as user.id) to Client and client uses this information to finish registration process.
2. When Client returns request for Authentication Finish process: UserHandle is returned empty. This only happens when Authenticating through Safari with Passkey using Android device.
3. I am passing User Verification to be `Required`.
Wondering if anyone is facing similar issue with this?
Thanks,
Tommy
--
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/fc20b8a8-79e9-4c7d-b71b-b066d4d40155n%40fidoalliance.org.
John Bradley <ve7...@ve7jtb.com>: Nov 18 05:25PM -0800
Android doesn't currently support discoverable credentials/passkey. Yes you can have it do UV. However it will not return a user. Id as the credential is treated as non discoverable. You are seeing the correct behavior.
There is an Android beta of Play services that adds support for discoverable credentials. You will get farther with that.
John B.
Sent from my iPhone
On Nov 18, 2022, at 4:24 PM, 'Tommy Chu' via FIDO Dev (fido-dev) <fido...@fidoalliance.org> wrote:
Hello everyone.
I am trying to develop Passwordless Login solution using WebAuthn standards..
Wondering if I could have your expert advise on one issue that has stalled me over few days already?
Reproducible Environment:
Authenticator: Android Passkey using QR code
Browser: Mac Ventura OS Safari
Server Dependency: Yubico: webauthn-server-core : 2.1.0
1. I am able to see that Server is providing UserHandle(as user.id) to Client and client uses this information to finish registration process.
2. When Client returns request for Authentication Finish process: UserHandle is returned empty. This only happens when Authenticating through Safari with Passkey using Android device.
3. I am passing User Verification to be `Required`.
Wondering if anyone is facing similar issue with this?
Thanks,
Tommy
--
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/fc20b8a8-79e9-4c7d-b71b-b066d4d40155n%40fidoalliance.org.
Ki-Eun Shin <shin...@gmail.com>: Nov 19 10:55AM +0900
I tried that scenario with my MacOS (Ventura 13.1) and Android (with Play
service beta).
1. Empty allow list: Safari and Chrome Canary browsers return the user
handle which is expected behavior.
2. With allow list (indicating created credential): Safari browser returns
empty user handle. But Chrome canary returns null user handle (( don't know
which one is correct behaviour)
With our demo site, handling three cases has no problem even if the user
handle is not included (null or empty), since we know the user id when we
get the assertion response.
Regards,
Ki-Eun Shin <shin...@gmail.com>: Nov 19 11:03AM +0900
I am digging the specification. And, the spec describes tht
> of userHandleResult
> <https://w3c.github.io/webauthn/#assertioncreationdata-userhandleresult> to
> null.
So, if the authenticator does not return an user handle, browsers need to
set it as null. So, Chrome Canary's current behaviour is correct.
And, since the credential is already populated from the RP side, the
authenticator might return *null* user handle. So, I'm thinking that
current behaviour is correct.
2022년 11월 19일 (토) 오전 10:55, Ki-Eun Shin <shin...@gmail.com>님이 작성:
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to fido-dev+u...@fidoalliance.org.
Reply all
Reply to author
Forward
0 new messages