- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Tue, 10 Oct 2017 10:20:16 -0400
- To: Roman Evstifeev <someuniquename@gmail.com>
- Cc: W3C Credentials CG <public-credentials@w3.org>
On 10/10/2017 06:45 AM, Roman Evstifeev wrote: > On 2 October 2017 at 17:38, Dave Longley <dlongley@digitalbazaar.com> wrote: >> On 10/01/2017 06:07 AM, Roman Evstifeev wrote: >>> >>> Hm...at the step of storing a passport narrator says that you should be >>> redirected to the credential handler website. The page really looks like >>> handler website (blue page header), but the url really does not change - it >>> still remains the issuer address... This is confusing. Is this just a demo >>> being incomplete yet? Or am I not getting how the process should look like? >> >> >> What you're seeing there is a "contextual window" which is a new concept >> where it's unclear how browsers will implement. They may end up just >> opening a new tab but it breaks the user out of the flow. > > Oauth2 flow opens new small browser window on top. This window has url > bar, that clearly indicates that I am on the auth provider page, and > connection can be trusted, as it is secured by tls. Also this page > says what remote site requested which permissions. I find this flow > less confusing than using iframe. Some drawbacks of that approach are: 1. On mobile as it will just end up acting like another window/tab given the size constraints. 2. On desktop it takes away valuable screen real estate. 3. It still doesn't prevent the user from getting "lost in the flow", e.g. "Where did that pop up window go? Why is my other window 'stuck'?" > >> Note that there really isn't a "redirection" in the sense that the browsing >> context *navigates* to another page. The existing page that launched the >> request must not lose its state. > > Hm, i am not sure what exactly is going on behind the scenes - is the > full code example avaliable anywhere? Yes, the code is available here: The demo code itself: https://github.com/digitalbazaar/credential-handler-demo The credential mediator polyfill: https://github.com/digitalbazaar/credential-mediator-polyfill The credential handler polyfill: https://github.com/digitalbazaar/credential-handler-polyfill Some supporting libraries: https://github.com/digitalbazaar/web-request-rpc https://github.com/digitalbazaar/web-request-mediator > What exactly that page needs to store? Can it be passed around in > callbacks, as oauth2 does? No, the state cannot be passed around via callbacks. The page makes a JS call and then waits on a Promise to be resolved with the result or an error. This mirrors what modern Web APIs do that the browsers are willing to implement, such as the Payment Request and Payment Handler APIs. Once the JS API call has been made, the internals use `postMessage` to send the details of the call (using JSON-RPC) to an iframe that is running the "credential mediator" (this piece acts as the polyfill for the browser functionality). The credential mediator shows the user some UI with preregistered "hints" -- and when a hint is chosen, the "credential handler" associated with it is loaded, in turn, in an iframe by the credential mediator. The credential mediator forwards the request onto the credential handler which performs implementation-specific processing and returns a response. This response is then forwarded back to the relying party website and the Promise is resolved to its value. The credential handler, if desired, is able to open a window to provide the user with a UI to complete the request. This is what is shown in the iframe with a contextual bar at the top that is rendered by the credential mediator origin. This same bar could be used to also display the origin of the credential handler, but it would not change the main URL bar which will still display the origin of the relying party. A separate window or tab could be launched instead for the credential handler's origin (and then the browser's URL bar would display that origin), but as mentioned, it has flow drawbacks. Sadly, it may be true that most users do not see or make use of the URL bar, particularly on mobile. Of course, that doesn't mean that showing the URL shouldn't be given preference over the UX issues, I'm just stating the problems. Hopefully this provides a bit more background. Thanks for the feedback! > >> >> The polyfill implements this "contextual window" by using an iframe that >> includes a UI message about what's going on above the iframe -- but it >> is true that it's not explicit which site you're on and I agree that's >> an issue. We're ahead of the browser implementations in this space so >> the demo is just trying to guess at what the experience will be in a >> browser or what the "best" experience *could* be. >> >> We're interested in feedback like this -- and suggestions for addressing >> it. Do you think that the user should be taken to an entirely new tab at >> this point (understanding the drawback where the user may "lose" their >> place if they click on other tabs) -- or should we just try to better >> visually include the origin of the wallet/repository site somehow? There >> is also limited real estate on mobile. We do expect that this will be >> easier for browsers since they have control over the chrome. >> >> >>> >>> On 26 September 2017 at 06:19, Manu Sporny <msporny@digitalbazaar.com >>> <mailto:msporny@digitalbazaar.com>> wrote: >>> >>> Hey Credentials CG (bcc: VCWG), >>> >>> I think you'll really like this. The engineering team at Digital >>> Bazaar >>> has been hard at work creating a production grade polyfill for both >>> the >>> Credential Handler API in Chrome, Safari, Edge, and Firefox. We're >>> doing >>> this to accelerate uptake of Verifiable Claims and Decentralized >>> Identifiers. We're announcing a beta release to developers today. >>> >>> An introductory video giving some background as well as recordings >>> showing it working in all major browsers can be found here (~6 minutes >>> runtime): >>> >>> https://youtu.be/qdbDu1oV0PI >>> >>> What does this mean for the Credentials CG work? >>> >>> * When the polyfill hits production, we expect that ~90% of all >>> browsers >>> (roughly 2.8 billion people) will immediately get support for the >>> Credential Handler APIs across desktop and mobile browsers. >>> >>> * Web developers won't need to wait for browsers to implement the >>> latest >>> Credential Handler API in order to deploy to their customers. >>> Instead, >>> the polyfill will provide missing browser features until the >>> browsers >>> support them. >>> >>> * This will enable us to more rapidly test and deploy new >>> verifiable claims features, greatly reducing the cost of >>> innovation in >>> the group, and enabling more people to participate in the design >>> and >>> development process. >>> >>> * This approach is not only compatible with DID-based authentication, >>> but empowered by it. You can see it how easy DID-based login is >>> in the >>> demo video. >>> >>> * Since this approach is almost identical to the Web Payments API, >>> which >>> all browser vendors are implementing, there is a high likelihood >>> that >>> this API will be technically acceptable to the browser vendors as >>> well. We're going to start that conversation with them in the >>> coming >>> weeks. >>> >>> What is next? >>> >>> * We'll submit a paper on this to Rebooting Web of Trust for >>> discussion. >>> >>> * We'll continue to harden the polyfill for production usage. >>> >>> * We'll pick an open license that works for all orgs and implementers. >>> >>> * We still need to implement some simple things, like better >>> animations/transitions when selecting identities/credentials. Some >>> CSS still needs to be fixed. >>> >>> -- manu >>> >>> -- >>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) >>> Founder/CEO - Digital Bazaar, Inc. >>> blog: Rebalancing How the Web is Built >>> http://manu.sporny.org/2016/rebalancing/ >>> <http://manu.sporny.org/2016/rebalancing/> >>> >>> >> >> >> -- >> Dave Longley >> CTO >> Digital Bazaar, Inc. >> http://digitalbazaar.com > -- Dave Longley CTO Digital Bazaar, Inc. http://digitalbazaar.com
Received on Tuesday, 10 October 2017 14:21:12 UTC