Siegel, Ellen:
>
> > From: [email protected] [mailto:[email protected]]
> > On Behalf Of Dave CROCKER
> >
> > I think there are two sources of confusion for this round of ADSP
> > discussion.
> >
> > The first is that the term "Author Signature" encourages one to think that
> > DKIM
> > is used to sign with the full author email address, rather than with the
> > /domain/ of the author's address. We fixed that error in the name of the
> > document, but forgot to carry it through to the details of the spec.
> >
> > DKIM is about domains, not email addresses. And that's all ADSP should be.
> > Using i= encourages this cofusion. Using "Author Signature" rather than
> > "Author
> > Domain Signature" also encourages it.
> [> ]
>
> I think you may have put your finger on the root of much of the
> interpretation differences. It might in fact be a really good idea
> to replace the term "Author Signature" with the term "Author Domain
> Signature" throughout the ADSP spec to help address this. It seems
> like the only real "author signature" would be a PGP type signature
> that is truly attached by the author rather than by some part of
> the email infrastructure on behalf of the author. Since the
> validated signing identity can only be a domain, it's inherently
> misleading to use a signature label that implies otherwise. I
> think we've all agreed that the information in i= is an assertion
> made by the signing domain rather than a validated signing identity
> in its own right, so we should make the spec terminology agree
> with that clarification. That doesn't denigrate the usefulness of
> that assertion data to various consumers, it just clearly
> distinguishes it from the identity/identifier of the signing entity
> itself.
>
> >
> > The specification and semantics of ADSP get simpler, cleaner and properly
> > scoped, when d= is used. Using i= really does invite a complex of issues
> > that
> > should be outside the scope of DKIM and ADSP.
> >
> > Use d=.
> [> ]
>
> +1
I am all for this.
+1
Wietse
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
