A side conversation with several people generated these two areas of interest to a verifier about the i= identifiers being generated by a signer:
1) Are the values stable? That is, will the same value be used by the signer each time a message is signed on behalf of a particular user/agent? Examples of stable values are [email protected] (such as AUIDs that use the same namespace as their users' email addresses), [email protected] (such as AUIDs based on the users' internal user IDs), and [email protected] (such as AUIDs based on a hash of the user name). Examples of unstable values would be ones that incorporate additional information within the i= value that is time varying, but is still able to be mapped to a single user's/agent's identity. 2) For stable values, is the namespace the same as the users' email addresses? That is, is the stable value the same as the user's email address? One suggestion made was to use key record t= value to communicate this information. Tony Hansen [email protected] Michael Adkins wrote: > I think there will be cases where a signer chooses to make their UAID > semantics known to assessors specifically for assessment purposes. How > the signer might communicate that to the assessors is out of scope for > the moment I think. I would assume that, for starters, the signers would > approach individual assessors/mailbox providers. If it proved useful and > was worth doing on a larger scale, then we could figure out a way to > make the signer's preference automatically known to assessors. > > > Siegel, Ellen wrote: >> >>> A question regarding the notes in 10 and 11: >>> >>> Would it make more sense to suggest that the mail system make the UAID >>> clear to the reader if its the identity whose reputation was used to >>> deliver the message, and make the SDID clear to the reader otherwise? >>> _______________________________________________ >>> >> [> ] >> Given that the semantics of the UAID are inherently opaque, how >> would you suggest that the mail system make the assessment? I like >> the concept, but don't see how it can be implemented given the >> defined syntax/semantics. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
