User designating multiple OPs to issue capability credentials about authorization-panel HOT 9 CLOSED

<https://alice.example/>
    solid:oidcIssuer <https://acme.example/>,
                     <https://yoyodyne.example/> .

Alice uses one WebID https://alice.example/ and delegates to two OPs rights to issue id_token for that WebID https://acme.example/ and https://yoyodyne.example/.

solid:oidcIssuer plays role in https://github.com/solid/webid-oidc-spec/blob/master/application-user-workflow.md#6-checks-issuer

from authorization-panel.

@bblfish Can someone describe the use case for one (Web)Id and multiple Id providers?

different ID providers might support different authentication/login schemes that might be appropriate to different environments (example: login/password for one, client certificate for another), or a user might be transitioning from one id provider to another, or one of them might be the OIDC self-issuer, or one of them might be a specially privileged intranet one and the other a more ordinary global one, or because the user feels like it and should be free to have as many issuers as she wants.

from authorization-panel.

zenomt suggested that OP could store results of user granting permission on consent screen to solid storage provided by the user.

not exactly. i have suggested that the user's permission grants to her apps be by URIs in location(s) designated by the user (in her profile), where the URIs are dereferenced to obtain the actual permissions granted to the app. i have suggested that a permission management app could be one way that permission grant documents can end up in an approved location, and that in some implementations an OP could do double-duty as the permission manager, which might yield a good user experience.

a document with a URI in an approved (according to the user's profile) location is just as good as a credential signed by an approved (according to the user's profile) issuer, but with no extra cryptography required (and it's a lot simpler).

the user could have any number of permission managers. the app just needs to know the URIs of its grant documents (presumably via a preference also maintained by the permission manager).

from authorization-panel.

I have created separated issue Client Capabilities: Verifiable Credential Proofs vs. Special discoverable prefix in storage solid/authentication-panel#60 to discuss details of verifying capability credentials presented by the client.

i have suggested that the user's permission grants to her apps be by URIs in location(s) designated by the user (in her profile), where the URIs are dereferenced to obtain the actual permissions granted to the app. i have suggested that a permission management app could be one way that permission grant documents can end up in an approved location, and that in some implementations an OP could do double-duty as the permission manager, which might yield a good user experience.

the user could have any number of permission managers. the app just needs to know the URIs of its grant documents (presumably via a preference also maintained by the permission manager).

I think for that to work client could only present capability credentials created after user's interaction with consent screen. We have discussed possibility where OP based on result of user consent screen could produce credentials for specific audience. I think we still need to clarify use cases which would motivate such requirements, in case it comes into play, do you see a way to create audience specific client capability credentials 'on demand' ?

from authorization-panel.

by "audience specific", do you mean specific to the client to which it was issued (example: same app, different device), or do you mean different capabilities for different resource servers?

one way "client•device specific" (which i think will not accord with an ordinary user's expectations) can be accommodated is by ensuring each client•device instance has a distinct app id. "on demand" can be accommodated, should that ever be needed, by having an authorized location for these URIs be a dynamic API endpoint instead of simple storage.

"different resource servers" is already accommodated in my concrete proposal, where an acl:AppAuthorization applies either as default (acl:origin "*") or to a specific origin and potentially to a specific protection space/realm at an origin. one thing i've been considering for the presentation side is allowing multiple App Authorizations to be presented at once, so an app could present the default one and one specific for that RS. this could be accomplished by allowing an array (if using JSON, for example in a proof token), or multiple instances (if using an HTTP Link request header or POST body parameters).

being able to specify multiple App Authorization URIs at once can also be used for the "client•device specific" case (with OIDC) if some App Authorizations were to apply to a shared app id and some applied to a device-specific client id.

from authorization-panel.

Can someone describe the use case for one (Web)Id and multiple Id providers?

from authorization-panel.

or one of them might be a specially privileged intranet one and the other a more ordinary global one

I think we may need to specify that if client accepts WebID as user input, for cases where resolved WebID Profile delegates to multiple OPs, client SHOULD prompt the user to select one specific OP for that interaction. This would only apply to clients and RS just needs to verify that any of the OPs issued the token.

from authorization-panel.

client SHOULD prompt the user to select one specific OP for that interaction

Agreed. I think this would eliminate most problems that could be encountered.

from authorization-panel.

Authorization Agent mentioned it #29 (comment) would be responsible for AuthZ. OP only stays responsible for AuthN.

Authorization Agent indeed stores Access Authorizations in Authorization Registry on solid storage specified by the user in RegistrySet.

from authorization-panel.