Returning Profile Data

[dshanske]

As per discussion, proposing the addition of a profile field into the token endpoint return that contains an h-card in jf2 format.

As implemented in my test, this is a name and photo property at minimum, solely for the purpose of the client displaying these in the application that is authenticating. If more profile data is desired, then it could theoretically be added with a profile scope.

[dshanske]

As implemented in the WordPress plugin and Quill, this adds a profile field to the return of the authorization and token endpoint with following properties...Name, URL, Photo and Type(Card). So a standard JF2 object.

[dshanske]

I would suggest we leave it at minimal unless someone has s need for more in future

[Zegnat]

As mentioned in #23 @aaronpk (at least at that point) wanted to keep IndieAuth as straight-forward as possible. I wasn’t there for the original discussion that started this issue, but was it decided that this argument against microformats2 did not apply to JF2?

In other words: is the idea to link the IndieAuth spec to the JF2 spec? (Note that this will indirectly link IndieAuth to the mf2 spec.) Or will IndieAuth separately define a JSON object to return that just happens to match what JF2 does?

On the subject of the card object itself: JF2 uses the mf2 definition of properties, where name means the “full/formatted name of the person or organisation” (see wiki). I feel like someone’s full name may be something more suited to put behind a profile scope (shortly touched on in chat).

Instead I feel like it should be made clear that a name returned is more of a display name. That is a name that may be used instead of the URL that was authenticated with for display reasons. Of course you may very well make that your full name, but you should not feel required to do so.

Obviously a name does not have to be my actual name, and can already be a nickname. I just wonder if it would make more sense for IndieAuth to explicitly call it a “display name”. If we want to continue to use JF2 (which depends on mf2 vocab) we could default to nickname:

{
  "type": "card",
  "nickname": "Zegnat",
  "photo": "https://avatars3.githubusercontent.com/u/490579",
  "url": "https://github.com/Zegnat"
}

[swentel]

Do we have a proposal to just get the profile an a route ? Because if someone updates the avatarinstance, the only way to update in the clients is to logout and login again. Indigenous has a refresh option for accounts (updates endpoints, micropub config etc ..), so that would become another call which would make this process a bit more convenient.

[aaronpk]

The mf2 (and jf2) property "name" is already a display name. No need to change it to "display_name", and "nickname" is also not at all what we're going for here. I realize tying this to jf2 or mf2 vocab complicates things, and I would be fine defining explicitly the properties to return here, where it just so happens they coincide with the jf2 structure.

We already do define a response to a GET request at the token endpoint, but we could extend that to also return profile info. I think that's the easiest place to add it.

So to summarize, profile information would be returned in the following places:

• By the authorization endpoint in the response to authorization code verification
• By the token endpoint in the access token response when issuing an access token
• By the token endpoint in response to verifying an access token

[swentel]

By the token endpoint in response to verifying an access token

It took me a while to understand this until I read https://indieauth.spec.indieweb.org/#access-token-verification-p-3. I miss this type of request in the Drupal endpoint, so I need to add that, which is fine :) (note, don't worry, I do validate incoming requests, it's just tightly integrated internally)

However, the spec says this verification request can not contain user-identifying information. So the question is: do we change that, or do we introduce a GET parameter? 'profile' comes to mind of course. So it would become something like: https://example.org/token?profile. Somehow I prefer the second option, but I'm fine with whatever is decided.

[dshanske]

Where does it say it can not contain? It says it will not contain. And this is referring to the decision on what token endpoint to use. I think you are misreading it?

[swentel]

Ooh, yes, you are right, I completely misread this:

Note that the request to the endpoint will not contain any user-identifying information

Sorry for the noise. So the response of that call could also include the profile info.

[Zegnat]

I realize tying this to jf2 or mf2 vocab complicates things, and I would be fine defining explicitly the properties to return here, where it just so happens they coincide with the jf2 structure.

That by itself addresses most of my concern already. It will also give us the opportunity to clearly define name as an alternative name for the authenticated URL, which I believe is the actual use-case we are trying to address, rather than a personal name (or other such expectations people may have of h-cards/jf2 cards).

[swentel]

The Drupal module now supports all 3 cases of returning profile data.

[dshanske]

Proposing that the decision to return profile data at all be server/site specific. Implementations can either return basic profile data, or only return this if a 'profile' scope is requested. Otherwise, the profile scope can be used to request more profile information.

[jalcine]

This would require Indigenous to request a profile scope, no?

(Originally published at: https://v2.jacky.wtf//post/c203cef1-a03d-4dd8-b60a-bfb5ff48a0c1)

[swentel]

Possibly. However, Indigenous now parses the homepage when authenticating or updating endpoints to get author info. Should that also take that scope into account ?

Does quill ask for the profile scope ?

My personal preference would like david proposed: basic info always, 'profile' scope for more info. I'm not planning to add more info anyway in the drupal server initially, only username and picture.

[jalcine]

I’ll be aiming to add this to Koype!

(Originally published at: https://v2.jacky.wtf//post/ca0e6244-5056-4ca6-a13a-554b64e67776)

[dshanske]

Profile scope is for full profile data, basic can be returned without a profile scope. This is usually name, avatar, url.

[jalcine]

Has anyone implemented this as of yet? Right now, my endpoint returns only me but I can update it such that when `profile is requested, it’ll return:

"type": "card", "nickname": "jacky", "photo": "https://v2.jacky.wtf/media/profile-image", "url": "https://v2.jacky.wtf"

(Originally published at: https://v2.jacky.wtf/post/55cda676-9ea7-49d3-ac73-e933051467ff)

[swentel]

Drupal IndieWeb returns 'profile' by default on the authentication request, token verification and token response request. Indigenous also listens to it.

[dshanske]

IndieAuth for WordPress does

[dshanske]

Quill supports it as well

[aaronpk]

This has been added! https://indieauth.spec.indieweb.org/#profile-information