Ok. The key question there seems to me to be 'does the UAID namespace represent actual identities'? For most of the use cases I can think of for assessing the UAID, it doesn't really matter whether it matches the from address or not.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tony Hansen Sent: Monday, January 26, 2009 2:51 PM To: DKIM IETF WG Subject: Re: [ietf-dkim] RFC4871bis The only one of interest I've seen suggested so far was if the i= value was identical to the users' email addresses. But I could potentially see other possible values for the 2nd area of interest. Another way to frame the 2nd area of interest is: what type of namespace does the signer use, if they care to identify it? Tony Hansen [email protected] Michael Adkins wrote: > 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 >>> [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 >>> >>> >> >> > _______________________________________________ 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
