The stability part I agree with. For the second area of interest, are
you saying the verifier would only find it interesting if i= was the
same as the user's (for some definition of 'user') email address?
Dave CROCKER wrote:
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
emailaddress(_at_)domain(_dot_)example(_dot_)com (such as AUIDs that use the
same
namespace as their users' email addresses),
user10234912(_at_)domain(_dot_)example(_dot_)com (such as AUIDs based on the
users'
internal user IDs), and
ABCDEFGH123456789(_at_)domain(_dot_)example(_dot_)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
tony(_at_)att(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html