IdP term in spec (was RE: Delegation discussion summary)

2006-10-15 Thread Drummond Reed
Suggestion: sidestep the issue completely and in the spec -- and everywhere
else -- just call it OpenID provider. It's a simple concatenation of
OpenID and service provider, so everyone gets it, but nobody will
associate it with SAML or federation or anything else.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Johannes Ernst
Sent: Saturday, October 14, 2006 11:37 PM
To: specs@openid.net
Subject: Re: Delegation discussion summary

We call it identity host at NetMesh. It's close enough to identity  
provider so people understand it quickly, but does not have the  
provider part to it (duh).

On Oct 14, 2006, at 20:46, Scott Kveton wrote:

 I would propose that the term Homesite be used when prompting the
 user to type in their IdP. I think the term Identity Provider is
 overloaded and not user friendly.

 As per my last email I feel the same way about identity provider  
 as well
 ... I agree with Dick; too overloaded and not user friendly.

 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

Johannes Ernst
NetMesh Inc.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Discussion: RP Yadis URL?

2006-10-15 Thread Dick Hardt
I assume you are referring to the return_to URL?

Current libraries add all kinds of parameters to that URL, would you  
be suggesting that the IdP does a GET on the return_to URL with  
content-type of XRDS?

If so, then we should add that to the spec. I'd then like to get  
clear on what would need to be in the Yadis file for indicating the  
login_url.

-- Dick

On 14-Oct-06, at 11:43 PM, Johannes Ernst wrote:

 Given that the RP has at least one URL, we can perform regular  
 Yadis discovery on it. (Likely, all of the RP's URLs point to the  
 same Yadis document.)

 I don't think an extension to the protocol is needed.

 On Oct 14, 2006, at 22:39, Dick Hardt wrote:

 Currently there is no method for the IdP to learn anything about the
 RP.  As a path for extensibility, would anyone have a problem with
 having an optional parameter in the AuthN Request for the location of
 the RP's Yadis document?

 -- Dick
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

 Johannes Ernst
 NetMesh Inc.

 lid.gif
  http://netmesh.info/jernst




 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Discussion: RP Yadis URL?

2006-10-15 Thread Johannes Ernst
Yes. Or any of the other defined algorithms for obtaining the XRDS  
file, given the return_to URL.


On Oct 14, 2006, at 23:50, Dick Hardt wrote:


I assume you are referring to the return_to URL?

Current libraries add all kinds of parameters to that URL, would  
you be suggesting that the IdP does a GET on the return_to URL with  
content-type of XRDS?


If so, then we should add that to the spec. I'd then like to get  
clear on what would need to be in the Yadis file for indicating the  
login_url.


-- Dick

On 14-Oct-06, at 11:43 PM, Johannes Ernst wrote:

Given that the RP has at least one URL, we can perform regular  
Yadis discovery on it. (Likely, all of the RP's URLs point to the  
same Yadis document.)


I don't think an extension to the protocol is needed.

On Oct 14, 2006, at 22:39, Dick Hardt wrote:


Currently there is no method for the IdP to learn anything about the
RP.  As a path for extensibility, would anyone have a problem with
having an optional parameter in the AuthN Request for the  
location of

the RP's Yadis document?

-- Dick
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Johannes Ernst
NetMesh Inc.

lid.gif
 http://netmesh.info/jernst




___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Johannes Ernst
NetMesh Inc.



 http://netmesh.info/jernst




___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re[2]: Discussion: RP Yadis URL?

2006-10-15 Thread Chris Drake
Hi Drummond,

Don't forget we'll need some way for an IdP to discover the return_to
URL from an RP in the IdP-initiated scenarios (I'd suggest a META or
LINK tag in the web page that the RP displays for accepting a login,
so an IdP (or browser plugin agent!) can discover this by parsing
the referrer page directly.  There's a lot of anti-phishing work
taking place right now: such a scheme would allow OpenID instant
access to these new standards too.)

Kind Regards,
Chris Drake


Monday, October 16, 2006, 2:59:12 AM, you wrote:

DR +1. All of the defined algorithms for obtaining the XRDS document from
DR either a URL or XRI will be going into Working Draft 11 of XRI Resolution
DR 2.0 starting this week. So it seems all the OpenID Authentication 2.0 spec
DR needs to specify is that they work against the return_to URL.

DR =Drummond 

DR -Original Message-
DR From: [EMAIL PROTECTED]
DR [mailto:[EMAIL PROTECTED] On Behalf
DR Of Johannes Ernst
DR Sent: Sunday, October 15, 2006 12:00 AM
DR To: specs@openid.net
DR Subject: Re: Discussion: RP Yadis URL?

DR Yes. Or any of the other defined algorithms for obtaining the XRDS
DR file, given the return_to URL.

DR On Oct 14, 2006, at 23:50, Dick Hardt wrote:

 I assume you are referring to the return_to URL?

 Current libraries add all kinds of parameters to that URL, would  
 you be suggesting that the IdP does a GET on the return_to URL with
 content-type of XRDS?

 If so, then we should add that to the spec. I'd then like to get  
 clear on what would need to be in the Yadis file for indicating the
 login_url.

 -- Dick

 On 14-Oct-06, at 11:43 PM, Johannes Ernst wrote:

 Given that the RP has at least one URL, we can perform regular  
 Yadis discovery on it. (Likely, all of the RP's URLs point to the
 same Yadis document.)

 I don't think an extension to the protocol is needed.

 On Oct 14, 2006, at 22:39, Dick Hardt wrote:

 Currently there is no method for the IdP to learn anything about the
 RP.  As a path for extensibility, would anyone have a problem with
 having an optional parameter in the AuthN Request for the  
 location of
 the RP's Yadis document?

 -- Dick
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

 Johannes Ernst
 NetMesh Inc.

 lid.gif
  http://netmesh.info/jernst




 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

DR Johannes Ernst
DR NetMesh Inc.


DR ___
DR specs mailing list
DR specs@openid.net
DR http://openid.net/mailman/listinfo/specs



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Re[2]: Discussion: RP Yadis URL?

2006-10-15 Thread Dick Hardt
Hi Chris

Would you clarify these IdP initiated scenarios?

I envisioned that an IdP learned of an RP from the user have an  
initial interaction with the RP. The IdP would then save the RP URL  
for later use in case the user wanted to go back to the RP directly  
from the IdP.

-- Dick

On 15-Oct-06, at 10:30 AM, Chris Drake wrote:

 Hi Drummond,

 Don't forget we'll need some way for an IdP to discover the return_to
 URL from an RP in the IdP-initiated scenarios (I'd suggest a META or
 LINK tag in the web page that the RP displays for accepting a login,
 so an IdP (or browser plugin agent!) can discover this by parsing
 the referrer page directly.  There's a lot of anti-phishing work
 taking place right now: such a scheme would allow OpenID instant
 access to these new standards too.)

 Kind Regards,
 Chris Drake


 Monday, October 16, 2006, 2:59:12 AM, you wrote:

 DR +1. All of the defined algorithms for obtaining the XRDS  
 document from
 DR either a URL or XRI will be going into Working Draft 11 of XRI  
 Resolution
 DR 2.0 starting this week. So it seems all the OpenID  
 Authentication 2.0 spec
 DR needs to specify is that they work against the return_to URL.

 DR =Drummond

 DR -Original Message-
 DR From: [EMAIL PROTECTED]
 DR [mailto:[EMAIL PROTECTED] On Behalf
 DR Of Johannes Ernst
 DR Sent: Sunday, October 15, 2006 12:00 AM
 DR To: specs@openid.net
 DR Subject: Re: Discussion: RP Yadis URL?

 DR Yes. Or any of the other defined algorithms for obtaining the XRDS
 DR file, given the return_to URL.

 DR On Oct 14, 2006, at 23:50, Dick Hardt wrote:

 I assume you are referring to the return_to URL?

 Current libraries add all kinds of parameters to that URL, would
 you be suggesting that the IdP does a GET on the return_to URL with
 content-type of XRDS?

 If so, then we should add that to the spec. I'd then like to get
 clear on what would need to be in the Yadis file for indicating the
 login_url.

 -- Dick

 On 14-Oct-06, at 11:43 PM, Johannes Ernst wrote:

 Given that the RP has at least one URL, we can perform regular
 Yadis discovery on it. (Likely, all of the RP's URLs point to the
 same Yadis document.)

 I don't think an extension to the protocol is needed.

 On Oct 14, 2006, at 22:39, Dick Hardt wrote:

 Currently there is no method for the IdP to learn anything  
 about the
 RP.  As a path for extensibility, would anyone have a problem with
 having an optional parameter in the AuthN Request for the
 location of
 the RP's Yadis document?

 -- Dick
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

 Johannes Ernst
 NetMesh Inc.

 lid.gif
  http://netmesh.info/jernst




 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

 DR Johannes Ernst
 DR NetMesh Inc.


 DR ___
 DR specs mailing list
 DR specs@openid.net
 DR http://openid.net/mailman/listinfo/specs



 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re[4]: Discussion: RP Yadis URL?

2006-10-15 Thread Chris Drake
Hi Dick,

1. IdP's advertising a list of sites that accept OpenID - like the
   way PayPal list stores that accept their currency I guess.  It's
   annoying to a user to have to come back to the place they just
   clicked in order to click a second time in order to go where they
   wanted to in the first place...  Better to send them where they
   want when they click the first time...

2. Privacy and delegation: if we force the user to initially interact
   with the RP, this gives the RP the opportunity to profile our
   users, start collecting (and sharing with other RPs) correlating
   information about them, and otherwise destroys IdP ability to
   protect user privacy.

Basically - this comes back to your Discussion: bookmark login url
discovery message - and for the sake of additionally supporting
future security enhancements (eg: anti-phishing), I'd recommend we
place something inside the RP's login FORM page, like a META or
LINK tag, for browser agents to use, or IdPs to find via referrer
URLs.

Kind Regards,
Chris Drake


Monday, October 16, 2006, 3:36:53 AM, you wrote:

DH Hi Chris

DH Would you clarify these IdP initiated scenarios?

DH I envisioned that an IdP learned of an RP from the user have an  
DH initial interaction with the RP. The IdP would then save the RP URL
DH for later use in case the user wanted to go back to the RP directly
DH from the IdP.

DH -- Dick

DH On 15-Oct-06, at 10:30 AM, Chris Drake wrote:

 Hi Drummond,

 Don't forget we'll need some way for an IdP to discover the return_to
 URL from an RP in the IdP-initiated scenarios (I'd suggest a META or
 LINK tag in the web page that the RP displays for accepting a login,
 so an IdP (or browser plugin agent!) can discover this by parsing
 the referrer page directly.  There's a lot of anti-phishing work
 taking place right now: such a scheme would allow OpenID instant
 access to these new standards too.)

 Kind Regards,
 Chris Drake


 Monday, October 16, 2006, 2:59:12 AM, you wrote:

 DR +1. All of the defined algorithms for obtaining the XRDS  
 document from
 DR either a URL or XRI will be going into Working Draft 11 of XRI
 Resolution
 DR 2.0 starting this week. So it seems all the OpenID  
 Authentication 2.0 spec
 DR needs to specify is that they work against the return_to URL.

 DR =Drummond

 DR -Original Message-
 DR From: [EMAIL PROTECTED]
 DR [mailto:[EMAIL PROTECTED] On Behalf
 DR Of Johannes Ernst
 DR Sent: Sunday, October 15, 2006 12:00 AM
 DR To: specs@openid.net
 DR Subject: Re: Discussion: RP Yadis URL?

 DR Yes. Or any of the other defined algorithms for obtaining the XRDS
 DR file, given the return_to URL.

 DR On Oct 14, 2006, at 23:50, Dick Hardt wrote:

 I assume you are referring to the return_to URL?

 Current libraries add all kinds of parameters to that URL, would
 you be suggesting that the IdP does a GET on the return_to URL with
 content-type of XRDS?

 If so, then we should add that to the spec. I'd then like to get
 clear on what would need to be in the Yadis file for indicating the
 login_url.

 -- Dick

 On 14-Oct-06, at 11:43 PM, Johannes Ernst wrote:

 Given that the RP has at least one URL, we can perform regular
 Yadis discovery on it. (Likely, all of the RP's URLs point to the
 same Yadis document.)

 I don't think an extension to the protocol is needed.

 On Oct 14, 2006, at 22:39, Dick Hardt wrote:

 Currently there is no method for the IdP to learn anything  
 about the
 RP.  As a path for extensibility, would anyone have a problem with
 having an optional parameter in the AuthN Request for the
 location of
 the RP's Yadis document?

 -- Dick
 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

 Johannes Ernst
 NetMesh Inc.

 lid.gif
  http://netmesh.info/jernst




 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs

 DR Johannes Ernst
 DR NetMesh Inc.


 DR ___
 DR specs mailing list
 DR specs@openid.net
 DR http://openid.net/mailman/listinfo/specs



 ___
 specs mailing list
 specs@openid.net
 http://openid.net/mailman/listinfo/specs





___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Changing Terminology (was RE: IdP term in spec (was RE: Delegationdiscussion summary))

2006-10-15 Thread Scott Kveton
 I'd really prefer not to change terminology in the spec right now.
 Seems like something we should have thought about four months ago versus
 a week after we said it would be final.  There is nothing saying user
 friendly terms that map to spec terms can't be created for the time
 being.  I do however think there will need to be healthy discussion
 around them, that takes longer than a week.  :)

+1 to all points.

- Scott

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: Delegation discussion summary

2006-10-15 Thread Recordon, David
After re-reading this, other messages, and Dick's latest post, I
strongly feel that we should make the change to support both the
portable and IdP-specific identifiers within the protocol.

The two most compelling reasons to me are that it has the fewest
conceptual changes from OpenID Auth 1.x and the messages are very
verbose and explicit in both the request and response.  In addition, I
believe it will grant greater flexibility for extensions being built
atop the protocol as well as it provides useful features when working
with XRIs.

I appreciate the simplicity the one identifier approach presents, though
dislike changing the concept behind the protocol this late in the
drafting process.

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Josh Hoyt
Sent: Thursday, October 12, 2006 10:29 AM
To: specs@openid.net
Subject: Delegation discussion summary

Hello, list,

I'm sure that another message in your inbox with delegation in the
title makes most of you cringe, so I'm sorry for that.I hope that this
one gets us closer to resolving this issue.

I have attempted to summarize the proposed delegation mechanisms, as
well as the currently-specified delegation mechanism in a single
document. I have glossed over some issues and left out some of the
discussion, but I hope that I captured most of the important stuff.
After reviewing the discussion, I think that we are actually pretty
close to consensus on a course of action.

I have added one new thing in this write-up, which is that I have
started calling delegation portable identifier support, which gives
rise to the term portable identifier for what is currently called a
delegated identifier. I think that this terminology is a little easier
to understand and less loaded than calling it delegation.

My write-up follows.

Josh

OpenID portable identifier support
##

Portable identifier support allows an IdP to do authentication for an
identifier that was not issued by that IdP. It has two motivating use
cases [1]_:

  * allow users to use any identifier with any IdP

  * allow users to move an identifier between IdPs (prevent IdP lock-in)

Each portable identifiers has an IdP-specific identifier tied to it.
This identifier allows the IdP to know what credentials to require
before issuing an authentication response even though the IdP does not
control the portable identifier.

Throughout this discussion, I will assume that there is a portable
identifier called http://my.portable.url/; that uses an IdP-specific
identifier called http://my.idp.specific.url/;.


Current implementation
==

OpenID 1 [2]_ calls portable identifier support delegation. In this
implementation, the IdP-specific identifier is the only identifier that
is communicated between the relying party and the IdP. When a relying
party discovers that it is requesting authentication for a portable
identifier, it must keep that state available for processing the
response, since the response message does not contain the portable
identifier at all.

Request and response messages for this mechanism both use the following
field::

  openid.identity = http://my.idp.specific.url/

This mechanism has a few drawbacks:

 * The relying party must manage state information for the duration of
   the transaction.

 * The authentication messages are potentially confusing, since the
   authentication response is not meaningful without the context of
   the initiation, and the IdP-specific identifier does not even have
   to be a valid OpenID identifier.

  * The IdP *cannot* be aware that it is using a portable identifier,
   so the IdP cannot assist the user in making decisions for different
   identifiers. For example, a user might wish to be prompted for
   confirmation each time he used one identifier, but allow automatic
   approval for another.

  * IdP-driven identifier selection in the OpenID 2.0 specification (up
   to draft 9) cannot return assertions for portable identifiers,
   because the verification algorithm will fail.

  * Portable identifiers must be treated differently from IdP-issued
   identifiers by the code running on the relying party


Proposed changes


All of the changes to delegation that have been proposed retain the
important features of portable identifier support. Additionally, they
all retain the same basic structure, where the IdP-specific identifier
is available from the standard discovery process. Primarily, the
proposals change what data is available in the protocol messages, the
relationship of the request to the response, and/or the party who is
responsible for discovering the IdP-specific identifier for the portable
identifier.

Both of the proposed changes to the response messages include the
portable identifier in the authentication response. Changing the
response to contain the portable identifier removes the burden of
maintaining that state from the relying 

Re: Summarizing Where We're At

2006-10-15 Thread Chris Drake
Hi David,

What is the rush for?  There's a lot of unhappy people here due to
missing protocol elements.

I for one believe the lack of privacy considerations is an entire
OpenID killer.

Is there a reason why you've omitted my IdP-initiated login proposal
from your short list (also known as bookmark login url discovery)?

If you're not convinced of the importance of privacy - read your own
IdP home page: http://pip.verisignlabs.com/

  Verify your identity without compromising your privacy with PIP,
   the personal identity management system from VeriSign. 

Verisign chose Privacy as *the* most important and critical feature
that their IdP should support - does your PIP service plan to *use*
OpenID, and if so, how do you propose to handle privacy problems (eg:
RP's collaborating about users behind their backs) ?

Imposing an arbitrary time limit will result in an incomplete spec.

Kind Regards,
Chris Drake


Monday, October 16, 2006, 5:28:52 AM, you wrote:

RD So previously I had set the goal of the final draft coming out last
RD Friday, though we've missed that.  I'm resetting this bar to Wednesday
RD which means we need to wrap up discussion on proposals where there is
RD general consensus as well as accept that some proposals will not make it
RD into this version.  For all proposals, unless there is general consensus
RD they should be included by Tuesday evening they will not be included.

RD * Request Nonce and Name
RD  - Has been partially implemented, openid.nonce -
RD openid.response_nonce, no agreement on the need of a request nonce
RD specifically, rather discussion has evolved into allowing a RP to pass
RD appdata like in Yahoo's BBAuth.  No formal proposal on the table yet,
RD thus will not be included in this version.

RD * Authentication Age
RD  - Re-proposed today adding clarity in motivation, general consensus is
RD needed to add to specification.

RD * Remove setup_url
RD  - Little discussion and no general consensus to do so.  Rather seems
RD asking for feedback from checkid_immediate implementers on the parameter
RD would be beneficial at this time.

RD * Consolidated Delegation Proposal
RD  - Very active discussion, the only proposal I'm willing to stall the
RD spec for.  Seems very important a strong conceptual model is created at
RD this time.

RD * Change Default session_type
RD  - Proposed, no discussion yet.

RD * Bare Request
RD  - Proposed, no discussion yet.

RD I also feel strongly that no new proposals, except to update existing
RD ones, should be considered for inclusion in this version.

RD --David
RD ___
RD specs mailing list
RD specs@openid.net
RD http://openid.net/mailman/listinfo/specs



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: Summarizing Where We're At

2006-10-15 Thread Recordon, David
Hi Chris,
The rush is that 2.0 has been in a drafting phase for almost six months
now, with draft five being posted at the end of June.  While we
certainly can continue taking the time to make everyone happy, we
ultimately will never have a finished specification.

Rather I think it is important to make sure the core features missing
from 1.1, and problems with it, have been addressed.  This will then
allow other proposals to be written as extensions as well as worked into
future versions.  As to the proposals I've listed in each of my summary
emails, I only work off of the proposals listed at
http://www.lifewiki.net/openid/OpenIDProposals as I said I would at the
end of September
(http://openid.net/pipermail/specs/2006-September/000129.html).

Not trying to be harsh, but if we don't put a stake in the ground and
move forward then 2.0 will never be finished.

--David

-Original Message-
From: Chris Drake [mailto:[EMAIL PROTECTED] 
Sent: Sunday, October 15, 2006 7:09 PM
To: Recordon, David
Cc: specs@openid.net
Subject: Re: Summarizing Where We're At

Hi David,

What is the rush for?  There's a lot of unhappy people here due to
missing protocol elements.

I for one believe the lack of privacy considerations is an entire OpenID
killer.

Is there a reason why you've omitted my IdP-initiated login proposal
from your short list (also known as bookmark login url discovery)?

If you're not convinced of the importance of privacy - read your own IdP
home page: http://pip.verisignlabs.com/

  Verify your identity without compromising your privacy with PIP,
   the personal identity management system from VeriSign. 

Verisign chose Privacy as *the* most important and critical feature that
their IdP should support - does your PIP service plan to *use* OpenID,
and if so, how do you propose to handle privacy problems (eg:
RP's collaborating about users behind their backs) ?

Imposing an arbitrary time limit will result in an incomplete spec.

Kind Regards,
Chris Drake


Monday, October 16, 2006, 5:28:52 AM, you wrote:

RD So previously I had set the goal of the final draft coming out last 
RD Friday, though we've missed that.  I'm resetting this bar to 
RD Wednesday which means we need to wrap up discussion on proposals 
RD where there is general consensus as well as accept that some 
RD proposals will not make it into this version.  For all proposals, 
RD unless there is general consensus they should be included by Tuesday
evening they will not be included.

RD * Request Nonce and Name
RD  - Has been partially implemented, openid.nonce - 
RD openid.response_nonce, no agreement on the need of a request nonce 
RD specifically, rather discussion has evolved into allowing a RP to 
RD pass appdata like in Yahoo's BBAuth.  No formal proposal on the 
RD table yet, thus will not be included in this version.

RD * Authentication Age
RD  - Re-proposed today adding clarity in motivation, general consensus

RD is needed to add to specification.

RD * Remove setup_url
RD  - Little discussion and no general consensus to do so.  Rather 
RD seems asking for feedback from checkid_immediate implementers on the

RD parameter would be beneficial at this time.

RD * Consolidated Delegation Proposal
RD  - Very active discussion, the only proposal I'm willing to stall 
RD the spec for.  Seems very important a strong conceptual model is 
RD created at this time.

RD * Change Default session_type
RD  - Proposed, no discussion yet.

RD * Bare Request
RD  - Proposed, no discussion yet.

RD I also feel strongly that no new proposals, except to update 
RD existing ones, should be considered for inclusion in this version.

RD --David
RD ___
RD specs mailing list
RD specs@openid.net
RD http://openid.net/mailman/listinfo/specs




___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs