Develop Reference

FIDO2 / WebAuthn Heuristic discovery of ambient /pre-authorized user(s) at authentication time

Edit respose to #cody salas
Following on from your sensible and detailed break down: -
Require Username:
Yes this seems well understood. The RP prompts for username/other-id and finds all credentials that are offered up in an array to the authenticator. Peachy!
Usernameless:
I need the "nuance" you refer to please. What (if any) filter(s) is applied to the returned credentials?
Global scope === Windows Hello User
Google login(s)
Other App logins
My Windows Hello Identity does NOT work with my Yubikey so I can't test :-(
Shared Accounts:
Ok, forget about the Beatles analogy, let's imagine one user (Our ex-PM :-) with multiple identities. ScoMo-Treasury, ScoMo-Health, ScoMo-Resources etc. What does a wildcard GET return?
End Edit 1
UA Credential Safe interogation.
Scenario:
Tri-Bank has 1 or more registered users from this device (My Windows Hello PC "Bad Boy").
There is no active session or ambient user to the RP (sub)domain. (Seeing local/session storage deprecated but all cookies also expired)
I simply cannot see a usernameless login interaction possibility
I will investigate that UPVA is deterministic on multi-user device but the spec is not only non-canonical, it seems to be off in fairy land :-(
WRT: -
Authentication WebAuthn-3 and Authentication WebAuthn-2
Please expand on point .2
The script asks the client for an Authentication Assertion, providing as much information as possible to narrow the choice of acceptable credentials for the user. This can be obtained from the data that was stored locally after registration, or by other means such as prompting the user for a username.
Which spec can we refer to (CTAP-10?) that will enlighten us to what is returned to a GET call with an empty "allowCredentials"?
How can the RP refine the user selection granularirty without a .GET that either identifies a single user or returns new Error("non-deterministic");
Does no one else see this as pivitol?
If we always have to ask for username please just say "We always have to identify username first!"
Otherwise could the user be prompted for we have Ringo, and Paul registered; which one do you want :-(
And yes, I know Paul can't login to Ringo's account without his thumb. I'm alluding to the unacceptable disclosure of Ringo's financial activity to Paul. Probably not a big deal unless it was John :-)
Please explain the FIDO2 versus OAUTH2.0 philisophical diversions pros/cons here!
OAUTH2.0 :- Would you like to continue as dicky#gmail.com? Done! no password, biometric, PIN, blah, blah, blah, pre-authenticated and trusted
FIDO2 :- I've got a UPVA that I'll probably have to test you on or a number Authentication methods for a number of users that I'll get you to pick from
Sounds about right???

Let's break this problem down into three different sections: Requiring a username, usernameless logins, and shared accounts
Requiring a username
Using an identifier is the only way to narrow down which authenticators are acceptable for an auth session. Note the use of identifier. The spec calls out username as it's extremely common, and familiar to users, but another mechanism can be used as an identifier if your environment/requirements allows for it.
Also keep in mind that this flow works well for users who are using an authenticator or ecosystem that does NOT support discoverable credentials.
I have some development guidance here if you wish to see some expanded code samples.
This won't entirely solve your problem if you are using a shared Windows Hello account. All John has to do is type the identifier "Paul", type in the PIN/Fingerprint, and have access. Overall you don't want to share authenticators, but I'll touch on that later in this comment.
Usernameless login
Remember this login flow will only work for users in an ecosystem that supports discoverable credentials. You've mentioned Windows Hello so you are in good hands. In this flow a relying party sends an empty allowCredentials list because it has no idea who is triggering the auth session. The relying party is essentially saying "send over a credential, and I'll attempt to validate it". There's more nuance to this statement, especially depending on the identity provider you are using, but that's the overall gist.
Usernameless can be broken down further depending on if you're using a security key, or platform authenticator. But during the GET() ceremony all credentials tied to your current origin will be shown depending on the authenticator that you activate. So if you fingerprint into Windows Hello, all the credentials for the current origin tied into the single Windows Hello account will be shown. If you activate your security key, all the credentials on the device for the current origin will be shown that exist on the device.
Shared accounts/workstations
So we'll continue with your Beatles example above. They can all share one computer, but this is where you need to question if they should be sharing the same Windows Hello account. If you register a credential using the Windows Hello authenticator, then anyone with the PIN/Fingerprint to that account will be able to leverage credentials on the account + device combo.
At the end of the day this will depend on how many accounts are tied to your workstation.
If you are adamant about the Beatles all sharing one Windows Hello account, on one workstation, then maybe they need separate personal authenticators, like a security key. That way no matter who is using the shared account, they still have independent credentials (unless Ringo decides to register Windows Hello, rather than his security key)
Otherwise, if each Beatle has their own Windows Hello account, they could log out/login in whenever one of the lads needs to check their bank account. In this case they will only be shown the credentials tied to their specific Windows Hello account
Hope this helps
Update 8/22
Glad my responses are helping so far - see below for answers to your additional follow-ups
Usernameless nuance
When I say nuance, I’m mostly referring to the not “one size fits all” of identity/auth providers. I can give you the code to my project using Cognito, but if you’re using Azure AD then there might be differences in the parameters that you pass to your RP. MOST of the code and logic will look the same, but it’s the small differences that might require more/less data.
For instance, let’s say that both Identity providers A and B support WebAuthn, and both will support discoverable credentials/usernamless login. But imagine that A requires that you call to its API noting the user's identifier, and B can derive the identifier from the get() response. They both accomplish the same task, but require slight modifications to the implementation
Shared accounts
I ran a test on my Windows machine (Windows 10, Windows Hello consumer). I created a Discoverable credential on account A using Windows Hello. I signed out, and logged in as account B using Windows Hello. I attempted to login to the same website, but I was unable to use the credential created by account A as account B.
So if your PM creates a credential as ScoMo-Trasury, they won’t be able to use the same credential as ScoMo-Health.
The wildcard get() method will only return the credentials for the account currently logged into Windows.

Paypal check if user has already purchased something

Is it anyhow possible to check from a website with paypal js client lib and API's whether a user/customer has already payed for a digital downloadable good?
Is it possible to check whether the user has a valid subscription (which is payed)?
Is it possible to allow a purchase only once and paypal redirects the user back with a notice he already has purchased it?
What I like to achieve:
If the user has already payed for a document/subscription, he should not need to
pay a second time but rather directly get the download. My idea, if
the user previously payed for it, I'd like to replace the paypal pay
button with a download button.
The whole check should happen from the Website and not
server-to-server communication.
Download must no be secured if not payed. I do know this may NOT be secure and the user may be able to download the document without paying. That is okay, because this is a test whether the user is willing to pay for something and implementation should be as simple as possible for now.
I lack to find the functionality within the PayPal API's. I found the list payments, but for me this seems more like a server to server API or?

How do you know who the "user" is when they visit your site? Are you proposing having them log in to your site with their PayPal account? (Connect with PayPal integration?). That would be very unusual, and unsuitable for people who paid with PayPal as a guest.
So what you are proposing is somewhere between impractical and not possible.
Instead, you need to authenticate the user yourself -- provide them with a username/password to login, for example, or a unique link, though be warned such links could be shared. Then, once authenticated, check your own database as to whether they paid/subscribed or not. You need to maintain your own records.
Expecting a payment processing service to somehow do any of this for you is a misplaced expectation.
Typical implementations are to send an email with the download link, or to use a digital product delivery service such as for example e-junkie

Why should I hide "consumer secret"?

I'm currently writing a twitter client using javascript, then found out many people reminded javascript developers about not revealing "consumer secret". But they never said why.
So why is it so important to hide my consumer_secret? If anyone want to show my "via My_App" on his app, making the name My_App more famous, why should I worried about anything? After all, you can't get any useful information out of my consumer_secret, the user information is protected by both https and token_secret.

A malicious developer could create a spam application using your consumer secret. If enough spam accounts are using the spam app Twitter may disable the entire consumer key at which point your entire application will no longer work with Twitter.

You can think of the consumer secret as a password -- it identifies your client to the server. Anyone with your consumer secret can pretend to be your app.
So you need to keep it secure, and you don't want to "hide" it; you want to encrypt it. This should happen on the server, never in the javascript app that you send to the user.
You can find a lot of helpful information at Google's support page.

Auto-login a user to an external website?

I'd like to securely save a user's credentials to related web sites and automatically log them into those sites when they log onto ours. I understand there are some security implications to this, so I'd like others' feedback and see what has been successful for others in the past.
What technique have you used to auto-log the users in? I'd prefer not to have to duplicate the HTML form and submit it through javascript. This seems error-prone if the form ever changes. I tried putting the login form inside an iframe, but it seems like the owners of the site are able to block this (see attached screenshot). Do you know how they do this?
Secondly, what was your approach to save the credentials so that they were "safe".
...Peter

I would suggest using cookies to save a session certificate to the users machine. A good value for such a cookie would be;
userid, timestamp, hash(userid . timestamp . global_secret)
The value of global_secret needs to be very long (40 characters or so), to avoid people cracking the hash, as doing so would allow them to create their own credentials with other peoples user ids!
The 'other sites' would check for this cookie, calculate the hash using the cleartext values of userid, timestamp and the global_secret (which all sites know), check it against the hash supplied, if they match, then this is a valid certificate.
You would then need to check the timestamp and decide if this was a 'new' enough certificate to allow access.
This is the standard method.

Do not do this. Read the terms of services for each site (ie facebook):
https://www.facebook.com/terms.php?ref=pf
(3.2) You will not collect users' content or information, or otherwise access Facebook, using automated means (such as harvesting bots, robots, spiders, or scrapers) without our permission.
(3.5) You will not solicit login information or access an account belonging to someone else.
(4.8) You will not share your password, (or in the case of developers, your secret key), let anyone else access your account, or do anything else that might jeopardize the security of your account.
You put yourself and the user at risk.
These sites have an API for a reason, so I suggest you looking using those as a more "legal" approach.
So if you're trying to retrieve a facebook user's information, create an app, have them authorize your app, then retrieve the information through facebook's api (example). You can also post to their wall with this method.
https://developers.facebook.com/
https://dev.twitter.com/
https://developers.google.com/

The common method to auto login a user is to set an cookie with an random string. It have to be that the random string isn't guessable. At the server you check the cookie and if it matches then you login the user. But if your site isn't completely served with https everyone who can listen to the traffic can pretend to be the user. To increase the security a little bit you could implement that a random string is only valid for a view days and then the user has to login again and a new random string is generated. So if someone steals the cookie-id the attacker has only for a certain time access to the account.

OpenID: Single User Interface Supporting Both Email/Password and OpenID

I like the idea of OpenID, I really do. But few of my target users have even heard of it - yet. If I want to offer OpenID as an option, my only choice would seem to come down to offering BOTH email/password authentication AND OpenID.
I've seen several sites that use this combination and the idea seems unappealing to put it mildly. Placing both options on the same screen is distracting and pointless if only 10% of users will even care about OpenID.
So I'm wondering, how could I offer a single user interface that supports BOTH OpenID and email/password for authentication and account creation?
One possibility I've been considering is to use a single OpenID/email field that can detect whether an email or OpenID was used and then dynamically adjust the interface accordingly.
For example, an account creation page might start off with a single field labelled "email" with some unobtrusive text along the lines of "we support OpenID". If a user enters a url, then the interface switches to an OpenID account creation page (via JavaScript). If an email address is entered, nothing happens.
What's the best method you've seen for hiding OpenID from the average user, but at the same time letting tech-savvy users know that your site supports it?

I think the way Uservoice combines username+password with OpenID is elegant.
That said, I disagree with the argument of not using OpenID merely because few people have heard of it. If you offer a few login buttons like "Login with Google" and "Login with Yahoo" alongside your "or, create a new username and password for yourself", then you don't even have to mention OpenID, and yet most users will likely pick the more convenient (OpenID) option without even realizing what they're using (and that's good!)

Decided to do some checking around on my own. Turns out there's a much better idea out there. The term seems to be 'OpenID selector'.
There's a free JavaScript library called JavaScript OpenID selector that makes it easy to create this sort of thing:
alt text http://img9.imageshack.us/img9/1940/step1c.png
This article explains the main problem and the solution:
One of the key results of Yahoo's OpenID usability study was that users did not understand OpenID and what its logo stands for. Instead, Yahoo promoted the idea of giving users a sign-in button that simply said "Sign In with a Yahoo! ID" (though Chris Messina argues that this could be detrimental to OpenID in the long run).Google and its partners are taking a similar route and are basically bypassing any mention of OpenID itself in favor of a simple message saying "Sign in with a Google Account."
There's even a sample Rails application that rolls authlogic, openid, and the selector into a single package so you can see how everything fits together.

See how SO here does it. That's a good a example, I like your idea of adapting the system by entered email as well, this is a trick facebook uses to send out facebook invitations to other people in your address book.

Would something like the following work?
Link to Login Page.
Now this site is running DNN and obviously it could be redesigned to be friendlier for the users. But the key here is that the standard way to sign-in is presented as the default sign-in.
I would probably redesign that site's interface to put LiveID and OpenID in a border labeled with Alternative Login Methods (along with a button for more help on how to use them) as well as change the buttons to read Sign In Using LiveID and Sign in Using OpenID.