Allow RPs to provide their own terms of service and privacy policy URLs for "configURL: any" option

[aaronpk]

With the configURL: "any" option, it's possible (and likely) that the RP will not have a prior relationship to the IdP. This means there is no registration data the IdP can pull the terms of service and privacy policy URLs from. In these cases it would make more sense to let the RP provide its own URLs.

I am not exactly sure of the best solution to this, but wanted to file this issue while it's on my mind.

[samuelgoto]

Yeah, this seems like a plausible request, that would work within our privacy/security constraints.

Any precedence that we could use to follow here? Has this problem been solved before elsewhere?

A couple of things comes to my mind, that I don't know about enough, but figured that you might:

1. Didn't one of the early version of OpenID allow you to name your OP by URI? And, if so, didn't that OP need the RP's terms of service and privacy policies before they could release a token?
2. Wouldn't the dynamic client registration schemes help here? Isn't there a variation of it that we could use to allow the IdP to have these URLs?

I am not exactly sure of the best solution to this, but wanted to file this issue while it's on my mind.

If we were to solve this in browserland, I'm thinking maybe we could have a JS parameter that the RP could use to pass that? e.g.

const credential = await navigator.credentials.get({
  identity: {
    provider: [{
      configURL: "any",
      // .. other stuff
      termsOfService: "https://rp.example/tos.html",
      privacyPolicy: "https://rp.example/tos.html",
    }]
  }
});

[aaronpk]

maybe we could have a JS parameter that the RP could use to pass that?

Seems reasonable to me.

1. didn't that OP need the RP's terms of service and privacy policies before they could release a token?

I don't remember this being a thing. I'm trying to dig up screenshots of how it used to work, but documentation is sparse. From what I remember, it only returned the URL, no additional information. I don't see anything in the original spec that indicates other profile info is returned either: https://openid.net/specs/openid-authentication-1_1.html

I found examples of two confirmation/consent screens that only described releasing the URL to the RP:

[samuelgoto]

Another option that occurred in this thread was to make client_id a URL that is de-referanceable with static JSON metadata:

https://socialhub.activitypub.rocks/t/federated-credentials-api-developer-feedback-needed/3961/17

So, one variation here is to have the RP pass a URL where we can get the TOS and PP from (and, as suggested in the thread, the RP's logo / name).

Example:

const credential = await navigator.credentials.get({
  identity: {
    // The browser gets the PP and TOS from this URL
    relyingParty: "https://rp.example/metadata.json",
    provider: [{
      configURL: "any",
      // .. other stuff
    }]
  }
});

@ThisIsMissEm @anderspitman FYI

[aaronpk]

That would work, in which case you'd probably want to reuse the existing properties from OAuth Dynamic Client Registration called tos_uri and policy_uri.

[ThisIsMissEm]

@samuelgoto why relyingParty here, when else where we have client_id? did that get renamed?

[ThisIsMissEm]

But we'd likely need to do:

relyingParty: {
  url: "..."
  format: "oauth2"
}

Since OAuth and OIDC can differ in some ways, and for the same reasons in w3c-fedid/FedCM#591

[samuelgoto]

Ah, fwiw, another option that occurred to me that was suggested in the past (I can't find it anymore! but I do remember that this was proposed at some point), was to come up with conventions on where to find the PP and TOS in websites through .well-known files.

So, the browser could use the links https://example.com/.well-known/privacy_policy and https://example.com/.well-known/terms_of_service, and the RP is responsible for 302-ing that to the right places.

I don't know if that's good or bad compared to the other alternatives, but figured it was worth noting it down so that we can compare and contrats.

[aaronpk]

Here is an early draft that lets the client provide all of its own metadata hosted at a URL. I've already built this in to webmention.io's FedCM implementation https://drafts.aaronpk.com/draft-parecki-oauth-client-id-metadata-document/draft-parecki-oauth-client-id-metadata-document.html

[yi-gu]

Is it possible for the RP to render their own PP/TOS after receiving the token? Not sure if this has to be done from the browserland. A typical UX could be:

1. User has gone through the FedCM flow without seeing PP/TOS
2. Upon receiving the token, before completing the registration, ask users to grant further permissions in a customized UI with PP/TOS/whatever.
3. If user accepts, proceed with sign-up; otherwise, drop the token and ideally call IdentityCredential.disconnect to reset the browser knowledge