consider alternatives for app registration discovery

[elf-pavlik]

I think we can still improve how app discoveries its registration. First simple adjustment would be to publish an URI Template that app can discover.

Another approach would be that after consent from the user, the app is being provided with IRI of its registration. If app looses that information it just tries to register again and agent which would present consent screen can skips that step and again just provides existing registration reference to the app.

[elf-pavlik]

I'm thinking about ways for app to ask about location of their registration. Authorization Agent could respond to authenticated request from an app with location of their Application Registration in HTTP Link header.

[elf-pavlik]

I'm going to implement HTTP Link header approach, as follows:

1. Check user's WebID Document for statement with interop:trustedAuthorizationAgent
2. Send authenticated request to IRI in object position and check HTTP Link header with relation http://www.w3.org/ns/solid/interop#requesterApplicationRegistration

I find it simpler and more straight forward than rummaging through registry sets using hash of application identity.

We should also follow up on #98 since possibly only Authorization Agent will need a 'total entry point' and it has trusted agent status.

[elf-pavlik]

Actually we could even reuse terms used for ApplicationRegistration in example from Primer we find:

alice-auth:bcf22534-0187-4ae4-b88f-fe0f9fa96659
  a interop:ApplicationRegistration ;
    # [...]
  interop:registeredApplication <https://projectron.example/#app> .

Application after discovering user's authorization agent could make simple authenticated HEAD request end expect to find in response:

Link: <https://projectron.example/#app>;
      anchor="https://auth.alice.example/bcf22534-0187-4ae4-b88f-fe0f9fa96659";
      rel="http://www.w3.org/ns/solid/interop#registeredApplication"
      

Based on that application making authenticated request knows location of its Application Registration.

[justinwb]

This is a nice approach - certainly much better / lighter weight for client implementations. I believe there may still be a benefit to having a low-tech option, but I could see this being the favored approach and maybe the right way long-term.

[elf-pavlik]

I implemented mentioned HTTP Link header mechanism in sai-js

[elf-pavlik]

If we only specify approach based on HTTP Link header #76 will become irrelevant.

[woutermont]

Right, so, I know this is old, and at the time seemed like a good idea to me, but I'd like to revisit this in light of a discussion I had with @timbl at todays meeting with the WebID-Profile panel, since this is precisely the part of the spec extracted in the Agent-Specific Discovery draft.

The worry seems to be that we provide a complicated way of discovering agent-specific data, while this could be done more simpler in the old hashed URL way.

I propose that we do a quick recapitulation of the pros and cons.

Edit: for visibility @justinwb @elf-pavlik

[elf-pavlik]

I think we should just continue in #291