DPoP support

[thhck]

As described here , Solid-OIDC uses Demonstrating Proof of Possession ( DPoP )

To make it work with FedCM, I had to pass the DPoP header through the optional FedCM nonce parameter of navigator.credential.get, but it would be nice to have a dedicated optional field.

Something like:

navigator.credentials.get({
  identity: {
    providers: [{
      nonce: "not-a-nonce",
      clientId: "yourClientID",
      registered: true,
      dpop: "dpopHeaderString",
    }]
  }
});

[cbiesinger]

w3c-fedid/custom-requests#2 proposes a mechanism to pass custom data to the ID assertion endpoint, that probably would work well for this?

[bc-pi]

For posterity - DPoP is definitely not "Decentralized Proof of Possession"

[thhck]

For posterity - DPoP is definitely not "Decentralized Proof of Possession"

Woupsi.. thanks , edited the original post.

w3c-fedid/custom-requests#2 proposes a mechanism to pass custom data to the ID assertion endpoint, that probably would work well for this?

Yes from my current understanding w3c-fedid/custom-requests#2 would solve this issue.

[samuelgoto]

I had to pass the DPoP header through the optional FedCM nonce parameter

Ha, that's industrious!

Yes from my current understanding w3c-fedid/custom-requests#2 would solve this issue.

Glad to hear! We designed it for this specific case.

We'll mark this closed when w3c-fedid/custom-requests#2 gets further along.

[cbiesinger]

On second thought, we believe that w3c-fedid/custom-requests#2 will fully fix this issue so let's just close this as a duplicate of that one. But feel free to reopen.

[panva]

Using parameters passable by w3c-fedid/custom-requests#2 does not in my opinion solve the issue of supporting DPoP.

It merely creates a passable workaround that allows the DPoP Proof to be present at the assertion endpoint (not in its usual place, which would be a header, so it would need profiling by the IETF OAuth WG to be interoperable). What that does is that IF the assertion endpoint deems the request solveable it might issue a sender constrained access token.

If the assertion endpoint deems interactions are necessary and triggers the Continuation API (is that its name?) the IdP will need to remember the DPoP Proof up until it the point deems to call IdentityProvider.resolve() with a sender constrained access token.

More and more I incline towards not giving FedCM back an actual Token artifact but rather the "authorization endpoint response" - code/code id_token/id_token. /@samuelgoto this is what we also discussed at OSW./. It's unfortunate the FedCM return is called "token" and that its type is strictly just a string. I would much rather see the return be freeform JSON, otherwise we'll have to resort to stringifying the JSON responses and getting them from a "token" property then feels like a hack, albeit likely intentional.

[thhck]

Thank you @panva for this insight.

I would like to rectify my previous comment, which might have been premature: While w3c-fedid/custom-requests#2 provides a workaround that enables Solid-OIDC to work with FedCM in my specific case, I cannot confidently say it addresses the broader application or standard practices for DPoP within the FedCM flow, as I'm still learning about the intricacies of these implementations.

[samuelgoto]

Using parameters passable by https://github.com/fedidcg/FedCM/issues/556 does not in my opinion solve the issue of supporting DPoP.

Can you expand on this more? Can you delineate and expand, specifically, in what ways would DPoP not be able to be used in conjunction with FedCM?

That is, is there anything else that isn't already captured in #579, https://github.com/fedidcg/FedCM/issues/578 and #536?

If so, happy to re-open this issue with any other remaining issue that's concrete and actionable.

not in its usual place, which would be a header, so it would need profiling by the IETF OAuth WG to be interoperable

It was a deliberate choice, through real world production feedback, to decouple the FedCM endpoints from the OAuth endpoints, to allow them to co-exist independently and autonomously.

Is this addressed as #536?

the IdP will need to remember the DPoP Proof up until it the point deems to call IdentityProvider.resolve()

Yep, that sounds right to me.

More and more I incline towards not giving FedCM back an actual Token artifact but rather the "authorization endpoint response" - code/code id_token/id_token.

That's roughly how we think about the response too: it would typically contain a code/code id_token/id_token.

Are you suggesting that we picked a bad name "token"? That seems fair, but I wanted to be clear if we are having a discussion about the name or its properties.

If so, I kicked off this issue here to track that specifically:

#579

I would much rather see the return be freeform JSON, otherwise we'll have to resort to stringifying the JSON responses and getting them from a "token" property then feels like a hack, albeit likely intentional.

Taking JSON is perfectly reasonable, IMHO. I kicked off this issue to have a more specific DPoP agnostic discussion here: https://github.com/fedidcg/FedCM/issues/578.

[panva]

Using parameters passable by w3c-fedid/custom-requests#2 does not in my opinion solve the issue of supporting DPoP.

Can you expand on this more? Can you delineate and expand, specifically, in what ways would DPoP not be able to be used in conjunction with FedCM?

That is, is there anything else that isn't already captured in #579, w3c-fedid/idp-registration#13 and #536?

If so, happy to re-open this issue with any other remaining issue that's concrete and actionable.

not in its usual place, which would be a header, so it would need profiling by the IETF OAuth WG to be interoperable

It was a deliberate choice, through real world production feedback, to decouple the FedCM endpoints from the OAuth endpoints, to allow them to co-exist independently and autonomously.

Is this addressed as #536?

I get why you'd want to decouple FedCM from how OAuth works. But as far as I can see we're pushing a square peg through a round hole now. #536 allows to pass what are authorization endpoint parameters to an assertion endpoint that's meant to issue token endpoint like responses as well as authorization endpoint like responses? Two entirely different behaviours / responsibilities.

More and more I incline towards not giving FedCM back an actual Token artifact but rather the "authorization endpoint response" - code/code id_token/id_token.

That's roughly how we think about the response too: it would typically contain a code/code id_token/id_token.

Are you suggesting that we picked a bad name "token"? That seems fair, but I wanted to be clear if we are having a discussion about the name or its properties.

Both.

If so, I kicked off this issue here to track that specifically:

#579

I would much rather see the return be freeform JSON, otherwise we'll have to resort to stringifying the JSON responses and getting them from a "token" property then feels like a hack, albeit likely intentional.

Taking JSON is perfectly reasonable, IMHO. I kicked off this issue to have a more specific DPoP agnostic discussion here: w3c-fedid/idp-registration#13.

👍 Although, you see the two separately, I see them combined. "token" is perfectly fine if all you expect to return is the final assertion. But that's clearly no longer the case. Fine, call it "response", and it needs to be anything JSON-serializable (object, string, ...), fine. I felt like getting rid of a predefined field altogether and just going with "anything goes", but I can get behind just response if we don't hamstring it by being just a string.