Fetching should be defined in terms of Fetch

[annevk]

Requirements such as

This request MUST NOT follow HTTP redirects and instead abort with an error if there are any.

are not needed if this specification would build on top of Fetch. That would also address a number of other things that are unclear, such as referrer handling, etc.

[cbiesinger]

duplicate of issue #188. (what is unclear about referer handling?)

[annevk]

How is it clear? :-)

[cbiesinger]

Heh. Well each endpoint specifies whether it is sent or not, e.g.:
https://fedidcg.github.io/FedCM/#idp-api-client-id-metadata-endpoint

c) with a Referer header indicating the RP's origin (as if Referer-Policy: strict-origin was in use)

I don't disagree with the fetch suggestion, but is that line not clear?

[annevk]

Ah, fair, that's actually pretty clear (though can a referrer policy override it?), though the algorithm I was looking at https://fedidcg.github.io/FedCM/#browser-api-rp-sign-in does not seem to specify anything.

[cbiesinger]

Ah yes. That should be better integrated with the other section, thanks for pointing that out

[cbiesinger]

I'm going to reopen this issue and narrow the scope to clarifying that issue

@npm1

[cbiesinger]

(I can't figure out how to change the title of a github issue...)

[annevk]

(next to the green "New issue" button there's a gray "Edit" button, both to the right of the heading)

[cbiesinger]

I must be missing some permission to do that :(

[npm1]

It may be only @samuelgoto has the permissions to edit...

[npm1]

We integrated one of the fetch calls in here https://fedidcg.github.io/FedCM/#check-the-root-manifest. Does this look OK? If so then we can move ahead and integrate the others similarly, if not let's improve the integration of that one more and then model the other ones on top of this one.