when using the "Issuer Discovery From Link Header" method, the issuer is linked to the PersonalProfileDocument, not to the Person inside that the issuer is actually vouching for. in other words, the subject of the link isn't the WebID. i don't think that's semantically right.

doing an HTTP OPTIONS on the location of the profile document takes at least one extra round-trip time (assuming you'll retrieve the full document eventually anyway and so will already be establishing a TLS+HTTP connection to the server) in order to potentially get not-really-right information. furthermore, ordinary web servers (on which it should totally be fine to host a profile document) are unlikely to provide this link relation in an OPTIONS call.

therefore, the first (and probably only) choice should be the one described in "Issuer Discovery From WebID Profile". the semantics are clean and correct, the functionality can be supported by any web server, and an unnecessary HTTP transaction and its round trip time are saved.

i propose striking the entire "Issuer Discovery From Link Header" subsection.