but, ummm..., this really would be a functional enhancement, and so it ought to be discussed as part of the broader RFC revision effort, and certainly under a different thread, such as the Subject I'm using here...
d/ Tony Hansen wrote: > 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 > emailaddr...@domain.example.com (such as AUIDs that use the same > namespace as their users' email addresses), > user10234...@domain.example.com (such as AUIDs based on the users' > internal user IDs), and abcdefgh123456...@domain.example.com (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 > t...@att.com > > 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 > -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
