credential-handler / authn.io Goto Github PK
View Code? Open in Web Editor NEWCredential Mediator Polyfill
Home Page: https://github.com/w3c-ccg/credential-handler-api
License: Other
Credential Mediator Polyfill
Home Page: https://github.com/w3c-ccg/credential-handler-api
License: Other
Just did a fresh install on the authn.io
branch and saw this notification:
> [email protected] postinstall /home/matt/dev/bedrock-dev/authorization.io/node_modules/acme-v2
> node scripts/postinstall
================================================================================
๐๐๐๐๐๐๐๐๐๐๐๐๐๐๐๐
๐ ๐
๐ Do you rely on Greenlock? ๐
๐ (or ACME.js) ๐
๐ ๐
๐๐๐๐๐๐๐๐๐๐๐๐๐๐๐๐
Hey! Let's Encrypt will STOP WORKING with Greenlock and ACME.js at the end of Oct 2019.
WITHOUT YOUR HELP we won't get the next release out in time.
If Greenlock (or ACME.js) has saved you time and money, and taken stress out of your life,
or you just love it, please reach out to return the favor today:
SAVE GREENLOCK / ACME.js:
https://indiegogo.com/at/greenlock
================================================================================
The README.md needs more information on:
To help with interop testing.
See: 5644f70
We need to add the ability to run backend and frontend tests.
A "Use a native app" option could be presented in the CHAPI UI that would send the pending CHAPI JSON request (would need a MIME type like application/chapi+json
or whatever) to a native application. The request would include a mediator URL for the native app to post the response back to. The response would then be forwarded via polling/push messaging to the user's browser that was waiting on the response from the native app -- and then sent onto the relying party like usual.
This feature (or one like it) would allow native applications to use the polyfill.
When logging in or requesting credentials authorization.io is engaged and asks user to "select an identity". The identities displayed show email address rather than the identity name the user chose when creating that DID. If the user has multiple identities associated with the same email address all they see is the same email address listed over and over again. I suggest displaying the Identity name rather than the email address.
The wallet registration UI ("[origin] wants to: Manage credentials"):
is too similar to the 'Allow notification UI':
Which was probably the original intention. However, usability tests show that since users have been trained to reflexively click 'Block' to Allow notification popups, they close the 'Manage credentials' popup without looking at it. (And then are confused about why they don't have a wallet.)
Proposal:
OSX Sierra, Node v6.9.1
The server runs fine, but tests throw an error:
$ npm test
> [email protected] test ~/code/authorization.io
> node authorization.dev.js test
~/code/authorization.io/node_modules/bedrock/lib/bedrock.js:115
throw err;
^
TypeError: Cannot read property 'vars' of undefined
at Object.<anonymous> (~/code/authorization.io/configs/test.js:39:12)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at ~/code/authorization.io/authorization.dev.js:18:3
at iterate (~/code/authorization.io/node_modules/async-node-events/lib/async-node-events.js:40:27)
2016-11-26T00:04:41.638Z - critical: worker 88648 exited with code 1
npm ERR! Test failed. See above for more details.
If a credentials request is made for the user's public key credential only, should we update the fixed callout at the top of the auth.io interface to indicate that? This flow is slightly different for the user than other flows in that they will not be redirected to their repo once they pick an identity, rather, picking an identity will complete the flow immediately. We might want to indicate somewhere on the UI whether or not a query requires the use of a repo or not so the user isn't surprised that they don't have a chance to cancel once selecting an identity.
The default icon for a handler (wallet) shows as a "globe" (which is the default website icon, not the default "wallet" icon) in the handler window header. The correct default icon (a "wallet" icon) shows on the wallet selection screen, but not once a wallet is selected and the handler window is shown.
When adding an identity, pressing the Enter key (mobile or PC) does not submit (Add) the form. The Add button must be explicitly clicked.
A native app and a browser tab running CHAPI could potentially communicate via WebRTC (Native app responds to a CHAPI request) if authn.io ran a WebRTC server for establishing peer connections. Explore this.
Non-Safari users do not need to hit the endpoint and do not need the v
cookie to enable cross-domain storage access. The cookie must not have SameSite=None
set or it will not work in Safari (at least as of today's date). Therefore, we should only set this cookie when a special endpoint is hit to prevent Chrome's warning that the cookie does not have SameSite=None
-- and generally because no cookies are needed for any browser other than Safari.
A "Quota Exceeded" DOMException may be thrown when trying to write to local storage, for example, when a user has very little free disk space. We should handle this error or pass it on more gracefully.
Any messages sent to/received from the REST API should be using JSON-LD.
When attempting to login to the issuer in step 2 of the demo, there are no mock credentials installed for the identity, causing the server to raise an Cannot read property '0' of undefined
error in tests/lib/idp.js
here: https://github.com/digitalbazaar/authorization.io/blob/0d2c18ae62097eba86bf44e5396ea14b5d62ddab/tests/lib/idp.js#L124
Its width seems to be set at 600px, is there a way to make it bigger?
Should we add a feature to allow people to cancel a request via a repo interface but allow them to make another identity choice at auth.io and try again? Or keep it simple and cancel all the way through to the consumer (like it does presently)?
This would only apply to credential queries, as storage operations include the identity the credentials were created for.
authorization.io doesn't need to allow any third party content, no special objects, media, etc. We should set a very strict CSP that will cause modern browsers to enforce this.
Add backend tests for:
Add frontend tests for:
Since the passphrase is intended to be long (for security) and since it has greater significance than just a single account on a particular service (rather it is used to remember a DID used for federated login), we should require a confirmation field to ensure people don't make simple mistakes and get frustrated later when their passphrase doesn't work.
When running through the demo, once you've logged into the Issuer, this occurs during identity composition and later during credential storage:
Unknown provider: brIdentityServiceProvider <- brIdentityService <- brCredentialsDirective
So it occurs at these urls (other request params omitted):
https://authorization.dev:33443/idp/credentials?action=request...
https://authorization.dev:33443/idp/credentials?action=store...
bedrock-angular-modal and bedrock-angular-selector have had major version releases which feature breaking changes.
We need to test with those new releases and apply fixes as needed.
An important component of CHAPI wallet operation will be "Just In Time" onboarding / wallet registration.
We want the user to be able to go through the following workflow:
To prevent the default wallet suggestion from having an unfair advantage, we can instead allow the requesting party (whichever app or web page is displaying the button that triggers the chapi get()
or store()
) to pass in one or more suggested wallet providers that the UI will suggest, in case the user does not have a wallet already.
So, here would be an example get()
request:
const credentialQuery = {
web: {
VerifiablePresentation: {
query: { ... },
challenge: '3182bdea-63d9-11ea-b6de-3b7c1404d57f',
domain: 'jobs.example.com',
suggestedWallet: [ "chapi-demo-wallet.digitalbazaar.com", "some.other.wallet.com" ]
}
}
};
const webCredential = await navigator.credentials.get(credentialQuery);
In this example, the two URLs in the suggestedWallet
parameter would be displayed in the "You don't have a wallet" CHAPI UI.
(add on to the JIT Onboarding/suggestedWallet issue)
In order to support a very common use case, where users first encounter a CHAPI UI button (such as 'Receive Credential' or 'Authenticate') without having a wallet, we need to support the workflow where the user:
get()
or store()
event.Since that last step is likely to take the user away from the original application they were on (especially if wallet login involves an email link), we need to provide a way to get the user back to the original requesting app (after registration).
This would be functionality similar to the OAuth2 / OIDC redirect_uri
component.
Proposal:
const credentialQuery = {
web: {
VerifiablePresentation: {
query: { ... },
challenge: '3182bdea-63d9-11ea-b6de-3b7c1404d57f',
domain: 'jobs.example.com',
redirectUri: 'requesting-app.example.com'
}
}
};
const webCredential = await navigator.credentials.get(credentialQuery);
The default fas-wallet
icon should be updated to use white when the user's preferred theme is dark.
We should pick a prefix and use it for angular components. eg: DataService
=> lhDataService
. Namespacing isn't built into angular 1.x so this is the common convention.
Report one.
When registering a new identity, if a duplicate email+passphrase is chosen, an error displays that says "Failed to register with the network. Try a different email address and passphrase.", however, the UI moves onto the next step showing you the information that will be sent back to your IdP, making it impossible to comply with the request to try a different email and passphrase.
We encrypt the proof-of-patience token here using AES:
https://github.com/digitalbazaar/authorization.io/blob/master/lib/proofs.js#L94-L100
Can we just use an HMAC instead? Does the data need to be hidden or do we just need to assert it hasn't been changed?
There's no need for a session cookie (it's there by default perhaps) and it should be removed.
Mentioned in #2 a while ago, but probably deserves an issue of its own.
In the meantime, AFAICT the application "routes" are in these files: https://github.com/digitalbazaar/authorization.io/search?q=routeProvider
Warning: I'm new to both this project and Angular. ๐ฌ
The code currently identifies the password-based key derivation method as "PKCS5" (see: https://github.com/digitalbazaar/loginhub/blob/bf2e0d0545df632a5205ca623e324d19010f3c7e/components/main.js#L79).
PKCS#5, however, describes multiple pbkd functions, so this is unclear. We should be using PBKDF2
, which refers to the specific function we use and is also the algorithm identifier used by the WebCrypto API: http://www.w3.org/TR/WebCryptoAPI/#pbkdf2
We currently use multiple routes for the credential agent and the credential polyfill API requires the appropriate agent URL to be provided in each API call. Also, when an API call occurs, the DOM is manipulated to add a dialog and iframe to the agent URL and then the user must wait for the iframe to load and show its UI. We have optimized this so it happens fairly quickly, but a better design can make it practically instant.
We can address all these issues with a new design:
To address these we should instead create a single route that handles all credential agent traffic. This keeps the organization simpler and the implementation more DRY on the auth.io end. The URL for this route can be set once on polyfill inclusion (with a default to auth.io) instead of passed for each call.
The polyfill can load this single URL into a persistent iframe that is only shown when a polyfill call is made. This way websites that use the polyfill can load the agent web application early and have it be ready to receive credential API requests as they occur on the page. It would allow for immediate rendering of the UI following a user action such as a button press.
When a cryptographic key credential query can be fulfilled without sending the user to their IdP, don't bother fetching the IdP's URL to get their service information.
The current directory structure isn't as well organized as it could be. We need to:
"did" is a URL scheme, don't use it as a term, use a different one.
https://github.com/digitalbazaar/authorization.io/blob/master/lib/mappings.js#L78
setDriverToConfig();
var error = new Error('No available storage method found.');
self._driverSet = Promise$1.reject(error);
return self._driverSet;
}
return driverPromiseLoop();
};
}
//# sourceURL=https://authorization.localhost:33443/modules/localforage/dist/localforage.js
this appears to have something to do with localforage.
Mocha and protractor tests are currently failing.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.