Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Returning Profile Data #31

Closed
dshanske opened this issue Feb 24, 2019 · 20 comments
Closed

Returning Profile Data #31

dshanske opened this issue Feb 24, 2019 · 20 comments

Comments

@dshanske
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member Author

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

@Zegnat
Copy link
Member

Zegnat commented Mar 2, 2019

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
Copy link
Contributor

swentel commented Mar 7, 2019

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
Copy link
Member

aaronpk commented Mar 7, 2019

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
Copy link
Contributor

swentel commented Mar 8, 2019

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
Copy link
Member Author

dshanske commented Mar 8, 2019

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
Copy link
Contributor

swentel commented Mar 8, 2019

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
Copy link
Member

Zegnat commented Mar 10, 2019

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
Copy link
Contributor

swentel commented Mar 11, 2019

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

@dshanske
Copy link
Member Author

dshanske commented May 7, 2019

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
Copy link

jalcine commented Dec 4, 2019

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

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

@swentel
Copy link
Contributor

swentel commented Dec 4, 2019

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
Copy link

jalcine commented Dec 4, 2019

I’ll be aiming to add this to Koype!

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

@dshanske
Copy link
Member Author

dshanske commented Dec 4, 2019

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

@jalcine
Copy link

jalcine commented Feb 21, 2020

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
Copy link
Contributor

swentel commented Feb 21, 2020

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

@dshanske
Copy link
Member Author

IndieAuth for WordPress does

@dshanske
Copy link
Member Author

Quill supports it as well

@aaronpk
Copy link
Member

aaronpk commented Sep 26, 2020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
5 participants