In the above sequence diagram, there are two XRDs involved: i.e., User XRD, and the AN’s XRD. The authentication endpoint is not written in the user’s XRD. It just has the link to the Authentication Provider and the concrete end point must be obtained from the AN’s XRD.
There are some security features involved here as well.
First, the user’s XRD is signed. Who should sign this XRD is still an open question. It may be application specific. For the interest of privacy, in the above case, I think it should use example.com’s certificate.
You should also note XRD/Link/ds:KeyInfo.
It has a list of public keys in it.
It says that the XRD of the AN must be signed by the private key corresponding to one of the public key in the list. This makes sure that the AN is the service that this user has intended to use.
Having been working on Digital Identity since 2000.
Co-author of various identity related specifications like OpenID Connect, JSON Web Token.
Chair of the OpenID Foundation (2011-)
Vice Chair of the OpenID Foundation (2010),
Founder of OpenID Foundation Japan (2008-),
Trustee of Kantara Initiative (2009-).