Confirmed users
1,022
edits
Labs/Identity/VerifiedEmailProtocol: Difference between revisions
Jump to navigation
Jump to search
m
→Secondary Authorities
| Line 178: | Line 178: | ||
}</pre> | }</pre> | ||
The presence of the issuer field tells the relying party that this is not a primary identity assertion. The relying party should decide whether they trust the issuer listed there; if they do, then they perform discovery on the provided email against the issuer's domain. The secondary authority relationship is probably pre-arranged; it is unrealistic to think that a relying party would trust an authority they had never heard of before. Although the lookup protocol could be issuer-specific, it would be simpler and more portable to just use the same lookup method that is used for the primary authority, (e.g.) webfinger. | The presence of the issuer field tells the relying party that this is not a primary identity assertion. The relying party should decide whether they trust the issuer listed there; if they do, then they perform discovery on the provided email against the issuer's domain. The secondary authority relationship is probably pre-arranged; it is unrealistic to think that a relying party would trust an authority they had never heard of before. Although the lookup protocol could be issuer-specific, it would be simpler and more portable to just use the same lookup method that is used for the primary authority, (e.g.) webfinger. | ||
<blockquote><font color=green>lookup method(s) should be part of the assertion (just like encryption). People always assume incorrectly.</font></blockquote> | |||
When they retrieve a public key, the relying party performs assertion verification as normal. | When they retrieve a public key, the relying party performs assertion verification as normal. | ||