What about a link relation type?

[dret]

It's a good idea to have a well-known URI for this, even though as I understand it, the typical use cases for well-known are cases when it's impossible to use embedded links for identifying a URI.
In this case, at least there's also the case for making the change-password-url discoverable from a resource (such as the home page of a user). I am wondering whether it wouldn't be useful to have a link relation type as well?

[tschoffelen]

This is somewhat addressed in the FAQ in the README.

The main concern is that using a <link> would not be useful to many of the applications implementing the client-side of this spec. Most of those being native password manager applications, they will want to refrain from parsing HTML in most cases. Doing a simple GET to a well-known URI and parsing the response headers is more within reach, and should therefore lead to a higher rate of adoption.

[dret]

The main concern is that using a |<link>| would not be useful to many of the applications implementing the client-side of this spec. Most of those being native password manager applications, they will want to refrain from parsing HTML in most cases. Doing a simple GET to a well-known URI and parsing the response headers is more within reach, and should therefore lead to a higher rate of adoption.

there's no need to parse HTML, it would be possible to add the link in the HTTP Link header field. the spec could make such a recommendation.

[hober]

there's no need to parse HTML, it would be possible to add the link in the HTTP Link header field. the spec could make such a recommendation.

Like we say in the FAQ, this would require keeping site-specific state client-side, verifying & invalidating said state periodically, etc.