User controlled Authorization App and App launcher proposal about authorization-panel HOT 9 OPEN

According to this blog post Service Workers! Your first step towards Progressive Web Apps Service Workers are limited to fetch from the Origin they were loaded from. (This may still make it useful for working with a Proxy server.)

There used to be something called Foreign Fetch but this was removed in 2017 from Chrome, see Remove foreign fetch #1188.

It could be that one can use WebWorkers for fetching remote documents, I am not sure.

from authorization-panel.

which makes the authenticated user quite vague: is it the user, the App, the Origin or a friend of the Origin that is authenticating

The token that we have set up does allow you to interpret what the user is.

jwtSign({
  "iss": THE_APP_ORIGIN example: "https://www.decentphotos.example",
  "aud": THE_RESOURCE_SERVER_BEING_QUERIED example: "https://bob.solid.example",
  id_token: jwtSign({
    "iss": IDENTITY_PROVIDER example"https://secureauth.example",
    "sub": USER_WEBID example: "https://alice.coolpod.example/profile/card#me",
    "aud": THE_APP_ORIGIN example: "https://www.decentphotos.example",
    "cnf":  CLIENT_PUBLIC_KEY
  }, IDENTITY_PROVIDER_PUBLIC_KEY)
}, CLIENT_PRIVATE_KEY)

Some things have been omitted from the token but as you can see, from this token you can deduce the app based on the origin and the user.

from authorization-panel.

Thanks for those details. I think during the teleconf we discussed quite a lot the problem of signing things with private keys made by remote apps. The problems were as follows

• If the token is not signed by a key owned only by the user, then such a token sent by the OAuth service can be forwarded by the App to it's origin or elsewhere, which can then also use it to authenticate. This is why there is a need to keep the life of OAuth tokens short.
• If the token is signed say by a key in the browser created by a less trusted App, then there is no way to limit the use of the private key: the less trusted App can forward the private key to it's origin or elsewhere to also sign such tokens.

The idea of having a trusted key store is that this would allow:

• signing of HTTP headers as with HTTP-Sig proposal without the private key being accessible to less-trusted apps.
• perhaps (I know less about OAuth) signing of OAuth token in a way that would guarantee that the less trusted App was not the one doing the signing, but that it was signed by a key in the control of the user. Perhaps by combined this with HTTP-Sig we can even tie the token to that session.

Another advantage of this App Launcher/Keychain is that it makes the "redirect_url" used by OAuth tokens now efficient. The launcher App knows which URL was launched in which frame, and so can precisely identify the current instance as a running of that app type. See the discussion on Origins and redirect_url in issue issue 22 of Authentication Panel: how are redirect_urls authenticated.

from authorization-panel.

This was discussed on Mon 7 Oct in the Authentication Panel, see Panel notes

from authorization-panel.

How would this work with use case described in https://github.com/solid/authentication-panel/issues/31 ?

from authorization-panel.

I don't see any difference as far as access control and authentication goes between RDF and other content @elf-pavlik . I implemented a Hyper Address Book in ScalaJS that could download RDF, people's pictures linked to from their foaf files, sign HTTP-Signature headers and display all that as a single page app.

from authorization-panel.

Must have accidentally closed the "close issue button"

from authorization-panel.

@bblfish if Bob shares with Alice https://bob.example/postcards/alice-b-day which responds only with text/html. When Alice navigates to that URL directly with her browser, how would you see Launcher App playing any role here?

from authorization-panel.

Ah I see. That could be an interesting use case for a browser plug-in.

from authorization-panel.