list of trusted apps should not be public

[michielbdejong]

currently it's in the user's public profile doc

[zenomt]

+1

"what apps i use" is both a privacy and a security concern. it should also not be possible (without my consent) nor necessary for

• a Resource Server to know about any apps i might use other than the app i'm currently using to access the RS;
• whatever app i'm currently using to know any other apps i use.

of course, the kinds of apps i use could be deduced by an agent from the presence of particular types of resources in my pod to which that agent has access (especially if an accessible resource says what app created it). i think this is a non-problem (or is at least out-of-scope).

[zenomt]

since the number of popular or embarrassing/compromising apps will be bounded (and not "big" in computing terms), it should not be possible to probe the user somehow to be able to answer "does the user use app A? how about B? ..."

the cases i'm looking to head off are "what if the 'list of trusted apps' used hashes instead of clear app identifiers" and "what if there were permission resources keyed by app id (or a hash of it) in some non-listable container".

[zenomt]

it should also not be possible (without my consent) nor necessary for

• a Resource Server to know about any apps i might use other than the app i'm currently using to access the RS

unless the RS is mine. it's ok if my resource server knows what apps i use/like/trust, because that sensitive information is contained to my realm of ownership.

[elf-pavlik]

interesting, how in that case some group resource server supposed to know if person authenticating with specific webid trusts the app they access resources on that RS with?

For example (acme) Resource Server in diagram below

[zenomt]

@elf-pavlik for one way, see #12. a Group Resource Server that chooses to honor a non-owner user's choices of trusted apps could present a management UI to the user and remember the user's preferences as given directly to the server. the server would only know about apps the user actually uses to access the server.

no matter what, it's ultimately up to the resource server to allow any kind of access to any of its resources regardless of what any outside agent says.

[elf-pavlik]

I think we need to reformulate this issue as requirement and have use case(s) illustrating where it comes to play. At the same time I would like to add use case where person chooses to have some app authorizations public and expects all resource servers to honor it. Somewhere in between I would see case where person stores a global app authorization on resource server of one's own choice and has a way to grand access to it to other resource servers she expects to honor it. That could work in various ways, RS expected to honor it can act as client and request permission with something like #28 , app could provide Capability URL to the app authorization which RS expected to honor it can use, app could provide full authorization signed by the user which RS could verify etc.

I see approach where RS expected to honor authorization, has to create it and store it on that RS applicable only to subset of all use cases and not addressing rest of the use cases.

[zenomt]

#48 describes a construction for keeping the list of the user's trusted apps private.

[elf-pavlik]

I think we agree that we need different approach than current experiment with using public list of trusted clients. We also seem to agree that approach we will propose will incorporate privacy requirements with respect which clients User has chosen to delegate some access to.

I will make PR with addition to success criteria capturing this requirement.

[elf-pavlik]

@jaxoncreed what else other than requirement added in #52 do you see needed to resolve this issue?

[jaxoncreed]

Oh I guess this is fine. We can close it.