Incorporate profile requirements from solid-oidc for Social Agents and Applications.

[justinwb]

The specification should do a better job incorporating requirements of Social Agents and Applications as stipulated by Solid-OIDC:

• Incorporate oidcIssuer into the Social Agent profile examples
• Reconcile Client Identifier Document and Application Profile

[justinwb]

It was determined in the Interop Panel on 10/26 that we should add solid:oidcIssuer to the Social Agent section of the spec to demonstrate how this spec and solid-oidc work together in a complementary way. It was also determined that an effort to standardize application / client profile documents across specs should be explored.

[jeff-zucker]

Well, coincidentally, I had been talking with @acoburn about client identifiers and came up with this example to see if I'd understood him. He says this works for him. What does it need to work for interop?

@prefix solid: <http://www.w3.org/ns/solid/terms#> .                         
@prefix interop: <http://www.w3.org/ns/solid/interop#> .                     
@prefix oidc: <https://www.w3.org/ns/solid/oidc#> .                          

<https://datakitchen.solidcommunity.net/profile/card#me>                     
    a interop:Application ;                                                    
    solid:oidcIssuer <https://solidcommunity.net> ;                            
    oidc:client_name "SolidOS Data Kitchen" ;                                 
    oidc:redirect_uris <https://datakitchen.solidcommunity.net/> .

[jeff-zucker]

Note that since this is on a Pod, I have included the oidcIssuer so an admin can use the issued WebID to login and manage the web app and profile.

[acoburn]

@justinwb for a little background on the format of Client Identifiers --

The Solid OIDC spec requires at least JSON-LD and using the ../solid/oidc-context.jsonld context is a SHOULD. This format has two advantages -- first, it allows apps to host static JSON-LD documents as part of their deployment. Many Solid apps are composed of static JavaScript, so this doesn't add a requirement for a content-negotiatable backend. Also, OpenID is a JSON-based system. With a JSON-LD serialization, we can treat these resources as plain JSON, which lowers the burden on OpenID server implementations.

And because these are JSON-LD documents, they can be easily extended with additional @context values and properties. If you would like assistance extending these profiles with an interop @context, I would be happy to help.

[jeff-zucker]

Is this close?

[{                                                                           
  "@context": [                                                              
    "https://www.w3.org/ns/solid/oidc-context.jsonld",                       
    "https://www.w3.org/ns/solid/interop-context.jsonld",                    
  ],                                                                         
  "@id":"https://datakitchen.solidcommunity.net/profile/card#me",            
  "@type":[
    "http://www.w3.org/ns/solid/interop#Application"
  ],                
  "https://www.w3.org/ns/solid/oidc#client_name":[{
    "@value":"SolidOS Data Kitchen"
  }],
  "http://www.w3.org/ns/solid/interop#applicationDescription":[{
    @value":"The SolidOS Databrowser as a native desktop app"
  }],                                         
  "https://www.w3.org/ns/solid/oidc#logo_uri":{
    "@id":"https://datakitchen.solidcommunity.net/favicon.ico"
  },                                              
  "https://www.w3.org/ns/solid/oidc#redirect_uris":[{
    "@id":"https://datakitchen.solidcommunity.net/"
  }],                                                  
  "http://www.w3.org/ns/solid/interop#applicationAuthor":[
    { "@value": "Tim Berners-Lee <timbl@mit.edu>"},
    {"@value":"Jeff Zucker <dubzed@gmail.com>"}
  ],                           
  "http://www.w3.org/ns/solid/interop#hasAccessNeedGroup":[...],             
}]  

[acoburn]

Try using a compact JSON-LD serialization. But generally that looks pretty good. The key thing will be to define the right context

[csarven]

Are all those things required in a profile?

Will the apps break down if a property is absent or includes a value that's not an expected type?

Are all those statements with object as URI required? Need to be dereferenced for any functionality? If not, why even 'require' it in a profile?

How does this look for a human- and machine-readable profile? Did anyone actually test/publish this?

Are there not "application", "software", ... classes in the wild? (There are tons!) What was considered/reviewed? Links to threads/minutes...

..

there is so much plumbing here that it genuinely scares me.

At least 3 namespaces to describe some basic aspects of... an application profile? Those are all separate requirements from different specs. If and when something needs to conform with one, they can 'paygo' (pay as you go). They shouldn't all be packaged up and sold as a requirement to the publisher of the profile.

[acoburn]

schema.org should have those types already defined.

[acoburn]

Also, a client_id profile is really meant to be simple and light weight. I also have concerns about having that serve so many different purposes simultaneously

[jeff-zucker]

@acoburn -

Also, a client_id profile is really meant to be simple and light weight.

I think many devs will want to do what I have done with data kitchen - put the client identifier document on a Pod that will also serve as the location of the web app. This means the profile needs the other kinds of predicates needed to manage a Pod. Perhaps those should go in a seeAlso document?

Also, in terms of developer buy-in "go put these needed security things online" is not the same as "go put details about your app online so that an automatic description of it can be generated. The first is a needed chore, the second is a welcome way to advertise.

I also see app details such as name and description being important to user control. I'd like to know what the apps I've given consent to are, not just their URIs.

[justinwb]

And because these are JSON-LD documents, they can be easily extended with additional @context values and properties. If you would like assistance extending these profiles with an interop @context, I would be happy to help.

No issues or objections with JSON-LD - any/all help is welcome and it looks like @jeff-zucker is already getting started (thanks jeff!). In the panel session earlier this week the action plan was also to work on JSON-LD and Turtle so I imagine other panel members will chip in too

Are all those things required in a profile?

I also have concerns about having that serve so many different purposes simultaneously

What is required for Solid-OIDC to operate, and what is required for someone to willing to use an application based on the information provided, and know what access to grant it to their data, are not the same thing. The premise of this issue is to allow the client identifier to be dereferenced for both purposes.

Also, a client_id profile is really meant to be simple and light weight.

The premise of this issue is to reconcile the differences, so it began with an acknowledgement that what we have is not yet streamlined, that there is some overlap that can be optimized, and some areas to iron out.

Overlaps (at a glance):

• client_name -> applicationName
• logo_uri -> applicationThumbnail

Added from interop:

• applicationDescription - a short summary of what the application is
• applicationAuthor - the individual or organization responsible for the application
• hasAccessNeedGroup - linking to one or more sets of access needs, which do not need to be located within the client identity document.

Given that we can optimize the overlap above, and in comparison with the requirements of solid-oidc, I don't believe the additional requirements from interop are surprising, scary, or unreasonable at all. Whether we can or should look at other vocabularies and/or properties is something we can and should certainly take up as part of the effort.

I also see app details such as name and description being important to user control. I'd like to know what the apps I've given consent to are, not just their URIs.

This is exactly right.

[elf-pavlik]

Note that since this is on a Pod, I have included the oidcIssuer so an admin can use the issued WebID to login and manage the web app and profile.

I would consider including solid:oidcIssuer in an Application Document as bad practice. Applications (clients) don't seem to own data, Social Agents (users / people / organizations) do own the data. If the Application Document is hosted in solid storage, some Social Agent would own it and they would preferably have a distinct WebID Document which would include their, Social Agent's not the Application's, solid:oidcIssuer.

In the end, if someone really wants to conflate a Social Agent with an Application they can use the same WebID for both, I would just discourage that practice.

[acoburn]

In the end, if someone really wants to conflate a Social Agent with an Application they can use the same WebID for both, I would just discourage that practice.

I very much agree with this

[jeff-zucker]

In the end, if someone really wants to conflate a Social Agent with an Application they can use the same WebID for both, I would just discourage that practice.

I very much agree with this

Me too, much cleaner. Silly of me to have done it the other way.

So is anyone aware of the current state of the notion of "owner"? Is control transferred by adding rights in the pod root .acl or by a predicate and if by a predicate, where should it occur.

[bourgeoa]

Implementation depends on the server. NSS uses podRoot/.meta :

# Root Meta resource for the user account
# Used to discover the account's WebID URI, given the account URI
<https://bourgeoa.solidcommunity.net/profile/card#me>
  <http://www.w3.org/ns/solid/terms#account>
  </>.

[jeff-zucker]

Seems sub-optimal, but okay, thanks for the info, I'll do that.

[jeff-zucker]

So if I transfer ownership of the pod in the way Alain described, the only way I can edit the app's pod as me is to give something like SolidOS Web App trustedApp status which gets written into the app's profile document Thus subverting the goal of keeping the app profile clean. :-(

[jeff-zucker]

The other option is to use NSS's implicit trust that profiles on it have it as IdP and just keep logging in as datakitchen but without an explicit oidc:issuer in the profile.

[jeff-zucker]

When/if trustedApp in the profile goes away (yes,please), this will no longer be an issue.

[bourgeoa]

@jeff-zucker the NSS implementation gives to the webId in that triple Control on all ACL's of that pod.

Beware that .meta has a .meta.acl

[bourgeoa]

There may be a need for NSS migration to add solid:oidcissuer to be compatible with CSS. There use to be an issue with solid/test-suite

[jeff-zucker]

Beware that .meta has a .meta.acl

Yes, I saw that. It's important because an owner may not want to disclose that they own the pod.

[jeff-zucker]

Here's another question about the app profile. SocialAgent profiles are "a foaf:PersonalProfileDocument". Is an app profile also?

[acoburn]

WebID profiles incorporate the foaf:PersonalProfileDocument type as a non-normative example from that draft specification. The Solid-OIDC draft has very consciously chosen not to call Client Identifier documents WebID profiles. So no such type is required. Nor is the sort of range-14 indirection required (e.g., 303 See Other or fragment URIs).

If you want to augment the type of an app profile, I would just use schema:SoftwareApplication