Trying to go through authorization flow with https://pod.inrupt.com/crspybits/profile/card#me

Build a Solid App
1

After having created a Pod with https://signup.pod.inrupt.com, I’m trying to use my authorization package https://github.com/crspybits/SolidAuthSwift.

The initial step in my authorization flow is dynamic registration:
Solid-OIDC →
Solid-OIDC →
Final: OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1

I’m using the issuer: https://broker.pod.inrupt.com (not quite sure if that’s correct, and not quite sure in general how one determines the issuer).

I’m getting a 400 HTTP response when I attempt to do the registration. Some details are here: https://github.com/crspybits/SolidAuthSwift/issues/3

My authorization flow is working for https://crspybits.solidcommunity.net/profile/card#me (using an issuer of https://solidcommunity.net) and for https://crspybits.inrupt.net/profile/card#me (using an issuer of https://inrupt.net).

Thoughts? Thanks!

1 Like
2

If you have a user’s WebID, it should contain a triple looking like <webid, http://www.w3.org/ns/solid/terms#oidcIssuer, https://some.issuer.url>. That’s one way to determine one’s issuer, and what’s nice is that it is mandated by the Solid-OIDC specification, which means it can be consistently used across WebIDs whoever their provisioner is.

I responded directly in the GH issue, but in summary, Inrupt’s broker and NSS Identity Provider (which powers both solidcommunity.net and inrupt.net) don’t support the same response type (which is totally valid per OIDC), so you’ll want to make sure you’re registering the subset of responses which are supported by all the Solid Identity Providers (or dynamically negotiate it when registering your client).

3

Thanks on both the webid/issuer and on the variations in support. I don’t have a firm grasp on these variations yet-- so will look at this.

On the webid front, it sounds like there some UX design consideration here. I had been considering a sign-in flow like

a) prompt the user for their issuer,
b) allow them to sign in via the redirect/web UI mechanism,
c) pull their webid out of the resulting id token.
d) extract info (e.g., storage location) from their profile using their webid

But perhaps this would be better:

a) Have them enter their webid
b) extract their issuer and storage location from their profile,
c) allow them to sign in via the redirect.

This has the advantage that they might be more likely to know what their webid is. Expecting a user to know what their issuer URL is seems questionable. At least for me so far knowing what the issuer URL hasn’t been easy.

4

I was just exploring this idea, and when I do:

MacBook-Pro-4:~ chris$ curl https://crspybits.inrupt.net/profile/card#me

I get:

@prefix : <#>.
@prefix acl: <http://www.w3.org/ns/auth/acl#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix schema: <http://schema.org/>.
@prefix solid: <http://www.w3.org/ns/solid/terms#>.
@prefix space: <http://www.w3.org/ns/pim/space#>.
@prefix pro: <./>.
@prefix inbox: </inbox/>.
@prefix crs: </>.

pro:card a foaf:PersonalProfileDocument; foaf:maker :me; foaf:primaryTopic :me.

:me
    a schema:Person, foaf:Person;
    acl:trustedApp
            [
                acl:mode acl:Append, acl:Read, acl:Write;
                acl:origin <biz.spasticmuffin.neebla.demo://>
            ];
    ldp:inbox inbox:;
    space:preferencesFile </settings/prefs.ttl>;
    space:storage crs:;
    solid:account crs:;
    solid:privateTypeIndex </settings/privateTypeIndex.ttl>;
    solid:publicTypeIndex </settings/publicTypeIndex.ttl>;
    foaf:name "Chris".

Unfortunately, in this case there’s no oidcIssuer :frowning:

5

I don’t know of any place in the spec that says that either of those MUST be in the profile. At best you can use those as possible locations to pick up information on the user.

As far as “extracting the issuer from the WebID” - how, other than hard-coding the way Inrupt operates are you going to extract the issuer from my webID https://pod.inrupt.com/jeff-zucker/profile/card#me?

[Edit : removed description of NSS & CSS profiles, needs checking]

6

That seems right to me with a fifth step :

e) provide fallback for data not found in the profile
7

Right, even though some WebID providers add a link to the storage of the WebID owner by default (e.g. https://pod.inrupt.com/, see https://pod.inrupt.com/zwifi/profile/card#me), that isn’t something mandated by the spec, and one cannot assume the presence of that link. However, the issuer being publicly advertized by the WebID is part of the Solid-OIDC specification. It is still a draft specification though, so there are moving parts still, and NSS should be regarded as a legacy prototype rather than a gold standard :). NSS has been implemented before Solid-OIDC, and it has very much informed Solid-OIDC of things that were valuable/harmful.

Even though that’s not the ideal UX, I agree with Jeff that for the time being, the only universal fallback is to ask the user what to do. I agree with you that the ideal flow starts from the user’s WebID, and your app can follow its nose from there, but that’s something that will only be possible in the future when the ecosystem is more mature, if ever. Right now, asking the user for their Identity Provider, but also potentially about the IRI to their Pod root or the place where they want your app to get/store data seems like a decent approach.