multiple issues with application-workflow.md

[zenomt]

this pertains to the application-workflow.md document as of revision 0956476 (since i'm referring to several steps by number, and they might change after i submit this).

there are multiple issues with this document, but for now i think it makes sense to talk about them all in one place. sorry for the length.

this workflow only works when the IdP is also the Resource Server. while it might be a common or even typical case, it's not the general case, and requiring it removes generality. in particular, it doesn't address the case where Alice's POD is not her IdP, nor the case where Alice wants to use DecentPhotos to access Bob's non-public photos at bob.example, to which Alice might have access.

step 4: that's not how client_ids are issued. see the continued discussion at #12. however, a dynamic registration request can include a logo, a client_name and a client_uri which can be presented to the user during the consent phase.

client_id is given by alice.example to DecentPhotos. alice.example could make the client_id be DecentPhotos's WebID, except how does alice.example verify the WebID? instead, alice.example could make the client_id be something that Alice agrees to, or associate a mnemonic name for Alice and ACLs translated to an internal client_id that's actually issued to DecentPhotos during Dynamic Client Registration.

steps 5, 9: just a refresh_token isn't what's desired here. one of the points of a refresh_token is so that access_tokens can be short lived, and Alice logging out will disable the refresh_token. given that DecentPhotos wants to run offline potentially far into the future, even if Alice is logged out, scope "offline_access" should be requested to get a special refresh_token. luckily, asking for this scope always requires special consent by the user.

step 13: ("if they weren't") this is only possible if the IdP and the RS are the same thing. there's no requirement in OIDC for an access_token to have any particular form (such as JWT) or to be inspectable by any party other than its issuer. the only thing a you can tell about an access_token is, if you also have an id_token that was issued with it, that the access_token goes with the id_token (via the at_hash claim).

step 14: alice.example knows that this is Alice, as issued to THE (according to Alice's consent at step 7) DecentPhotos.

step 15: there isn't necessarily a client_id in the access_token. the format of the access_token is determined solely by its issuer (see above). only the issuer really knows to which client the access_token was issued. whether the access_token is a JWT or a random key to a row in a database table (or "other") is an implementation detail.

it seems dangerous/scary for Alice to allow an app to automatically authenticate as herself even when she isn't logged in.

for the use case in this example, a more likely scenario that matches how services today (like github) work is that DecentPhotos will have/be a bot (that can have a WebID) to which Alice can grant read/write access to a portion of her POD, by modifying the ACLs. this would require a way for the bot to authenticate with alice.example. it's exactly the same problem as "Alice wants to use the DecentPhotos app to access Bob's photos at bob.example".

this is the case i referred to in issue #12. i also have a proposed solution linked to from there.