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
