Extend WebFiinger response to support `profile-page` Link Relation
Problem to solve
Knowing a Gitlab account (for example from OpenID connect, which already utilizes WebFinger) it would be cool to be able to link to the user's profile page in an automated and well defined fashion.
This could also be a very small step forward with #6468: If alice from gitlab1.example is somehow visible on gitlab2.example (for example in a merge request), then gitlab2 could use the WebFinger protocol (querying acct:alice@gitlab1.example
) to discover the profile page and provide a link to it. Gitlab already shows nice links to the profile page for local users.
Intended users
I would guess, Developers. Because this really implements a low level protocol that non Developers will seldom take a look at.
Maybe this persona?
User experience goal
Well, the ideal (developer) user story is, that they're just happy, because they already implemented WebFinger querying with the profile page for other sites and it just works with Gitlab now.
The second best thing is, that they can implement a well defined standard protocol in their code and interact with Gitlab (and other sites) in a well defined and standard compliant way.
Proposal
Let WebFinger return the profile page link rel property
Currently:
$ GET 'https://gitlab.com/.well-known/webfinger?resource=acct%3Ac.tacke%40gitlab.com' | jq .
{
"subject": "acct:c.tacke@gitlab.com",
"links": [
{
"rel": "http://openid.net/specs/connect/1.0/issuer",
"href": "https://gitlab.com/"
}
]
}
It should be extended to look like this:
{
"subject": "acct:c.tacke@gitlab.com",
"links": [
{
"rel": "http://webfinger.net/rel/profile-page",
"type": "text/html",
"href": "https://gitlab.com/c.tacke"
},
{
"rel": "http://openid.net/specs/connect/1.0/issuer",
"href": "https://gitlab.com/"
}
]
}
Further details
- "Link Relation: profile-page" - https://webfinger.net/rel/profile-page/
- WebFinger related specifications - https://webfinger.net/spec/
Permissions and Security
I can think of the following points:
- What to reply if the user does not exist at all? This question should have been resolved for the existing WebFinger implementation, but might be worth a revisit? This exposes the knowledge of existing users. Which might be a security threat?
- Let's assume the user exists and a WeebFinger response is to be send.
- If the profile of that user is anyway public, then an attacker can already guess the profile URL (append username to the instance-URL). So publishing the URL via WebFinger doesn't increase any security risks.
- If the profile page is not public (is that possible at all?), then one could hide that part from the WebFinger response. But including it wouldn't hurt anyway, as the profile page itself should be secured properly. And users with an account on that instance (and appropriate permissions) still could see it. So linking to the profile page could be beneficial in that case also.
Documentation
Possibly some "supported protocols" page should be extended, if that exists?
Availability & Testing
Risks:
- Probably very few
Tests:
- Test for proper webfinger response with all expected fields
- If the security considerations do give specific results, those should be tested as well
Available Tier
- Free
For one this isn't looking like a "top selling feature".
And really, it will slowly improve Federation!
Links / references
The avatar link relation might also be of interested?