Re: Proposing an OpenID Authentication 2.1 Working Group
Here's the output from today's IIW session on this: 2.0 has been finalized bunch of implementations found lots of spec bugs also gone and done oauth and email addresses and other things. Can we support these in the core spec? - Making the spec more readable and fixing bugs (eratta) - Delegation - Error handling - Adding a security appendix - could be a separate document referred to by the spec - possibly produced by separate group - Who controls this security page? - Security committee could look after this. - or Allen at Yahoo! will be editing a security document - Clarifying XRI - Currently there's no firm message about whether RPs MUST support XRIs or not. - Need to clarify how exactly XRI should be used with OpenID. - Similar to the whitelist question. - Clarify if RPs can white or blacklist what OPs they accept, and vice-versa. - Discovery of type of identifiers an RP supports. - Clarifying IRI - Updating discovery. Possibly including the new-fangled XRD discovery. - Clarifying whether association over SSL must/can use diffie-hellman. - Discovery of support of checkid_immediate. Exploratory work: - Signature mechanisms. Looking at additionally supporting the mechanisms defined in OAuth so that they can be closer together. - Possibly deprecating the current signature mechanism. - Public keys? - Email-shaped identifiers for OpenID - Could be a separate working group? There was consensus that email-shaped identifiers would be worked on by a separate group and possibly rolled into 2.1 if it's done in time. - Smart/rich clients? - Could be in this WG unless it ends up being a big change in which case it could be its own WG. - There's another session about this. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposing an OpenID Authentication 2.1 Working Group
Great notes! Thanks! Martin Atkins wrote: Here's the output from today's IIW session on this: 2.0 has been finalized bunch of implementations found lots of spec bugs also gone and done oauth and email addresses and other things. Can we support these in the core spec? - Making the spec more readable and fixing bugs (eratta) - Delegation - Error handling - Adding a security appendix - could be a separate document referred to by the spec - possibly produced by separate group - Who controls this security page? - Security committee could look after this. - or Allen at Yahoo! will be editing a security document - Clarifying XRI - Currently there's no firm message about whether RPs MUST support XRIs or not. - Need to clarify how exactly XRI should be used with OpenID. - Similar to the whitelist question. - Clarify if RPs can white or blacklist what OPs they accept, and vice-versa. - Discovery of type of identifiers an RP supports. - Clarifying IRI - Updating discovery. Possibly including the new-fangled XRD discovery. - Clarifying whether association over SSL must/can use diffie-hellman. - Discovery of support of checkid_immediate. Exploratory work: - Signature mechanisms. Looking at additionally supporting the mechanisms defined in OAuth so that they can be closer together. - Possibly deprecating the current signature mechanism. - Public keys? - Email-shaped identifiers for OpenID - Could be a separate working group? There was consensus that email-shaped identifiers would be worked on by a separate group and possibly rolled into 2.1 if it's done in time. - Smart/rich clients? - Could be in this WG unless it ends up being a big change in which case it could be its own WG. - There's another session about this. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Chief Architect AIM: gffletch Identity Services Work: [EMAIL PROTECTED] AOL LLC Home: [EMAIL PROTECTED] Mobile: +1-703-462-3494 Office: +1-703-265-2544 Blog: http://practicalid.blogspot.com ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposing an OpenID Authentication 2.1 Working Group
Yep, thanks! I'll be sending out a new charter shortly. On Nov 11, 2008, at 11:24 AM, George Fletcher wrote: Great notes! Thanks! Martin Atkins wrote: Here's the output from today's IIW session on this: 2.0 has been finalized bunch of implementations found lots of spec bugs also gone and done oauth and email addresses and other things. Can we support these in the core spec? - Making the spec more readable and fixing bugs (eratta) - Delegation - Error handling - Adding a security appendix - could be a separate document referred to by the spec - possibly produced by separate group - Who controls this security page? - Security committee could look after this. - or Allen at Yahoo! will be editing a security document - Clarifying XRI - Currently there's no firm message about whether RPs MUST support XRIs or not. - Need to clarify how exactly XRI should be used with OpenID. - Similar to the whitelist question. - Clarify if RPs can white or blacklist what OPs they accept, and vice-versa. - Discovery of type of identifiers an RP supports. - Clarifying IRI - Updating discovery. Possibly including the new-fangled XRD discovery. - Clarifying whether association over SSL must/can use diffie- hellman. - Discovery of support of checkid_immediate. Exploratory work: - Signature mechanisms. Looking at additionally supporting the mechanisms defined in OAuth so that they can be closer together. - Possibly deprecating the current signature mechanism. - Public keys? - Email-shaped identifiers for OpenID - Could be a separate working group? There was consensus that email-shaped identifiers would be worked on by a separate group and possibly rolled into 2.1 if it's done in time. - Smart/rich clients? - Could be in this WG unless it ends up being a big change in which case it could be its own WG. - There's another session about this. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Chief Architect AIM: gffletch Identity Services Work: [EMAIL PROTECTED] AOL LLC Home: [EMAIL PROTECTED] Mobile: +1-703-462-3494 Office: +1-703-265-2544 Blog: http:// practicalid.blogspot.com ___ 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: Proposal to create the TX working group
On 09.11.2008, at 20:51, Nat Sakimura wrote: As to AX+SAML (or for that matter XAdES) is concerned, that is a valid approach, but if I were to use SAML, I would use Just to clarify a technical detail: The XAdES example regarding Estonia you mentioned earlier does not include transporting XAdES payloads over OpenID AX (which seems to be the purpose of the discussed workgroup where the similarities of SAML over AX come in). The special behavior and out of band assurances given by openid.ee does not include anything new on the protocol level, just added semantics to basic OpenID transactions. If we could use PDF signatures as legally valid signatures in Estonia, it could be PDF based signatures instead of XAdES, or ODF signatures, or MS .doc signatures. FYI, openid.ee allows a RP to upload a contract (template) which must be agreed with and digitally signed (legally binding signature resulting in an XAdES document with the filled in contract signed by the user with an ID-card and stored on the OP) before the OP starts issuing positive assertions about the given user to the given RP. The contract could be a document of any kind (PDF, JPG, DOC, TXT) and the only thing that is transferred to the RP over AX is a 'secret url' from where the RP can download the signed contract (XAdES container with the possibly PDF contract in it). The actual assurance (that the user has signed the contract the RP has uploaded) comes from out of band agreements/contracts between OP and RP. The AX attribute is just an extra option, if the RP wishes to automatically fetch and store the signed contract somewhere. Basically it is an advanced and legally binding 'I agree with terms and conditions' checkbox built on top of standard OpenID. With legally binding I mean that it is dead simple in the court: Here are the terms and conditions you digitally signed and which you have violated as checking checkboxes and pressing 'continue' is not a legally binding action in Estonia, at least I don't know of any court cases about it. If you need an example use case, think of signing and faxing NDA-s before you can download some simple secret product documentation. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Proposal to create the TX working group
Just wanted to add that Nat is running a session on TX at IIW this afternoon. We should definitly chat about the needs being expressed in this thread and how they might be able to be solved with OpenID. --David On Nov 11, 2008, at 1:13 PM, Martin Paljak wrote: On 09.11.2008, at 20:51, Nat Sakimura wrote: As to AX+SAML (or for that matter XAdES) is concerned, that is a valid approach, but if I were to use SAML, I would use Just to clarify a technical detail: The XAdES example regarding Estonia you mentioned earlier does not include transporting XAdES payloads over OpenID AX (which seems to be the purpose of the discussed workgroup where the similarities of SAML over AX come in). The special behavior and out of band assurances given by openid.ee does not include anything new on the protocol level, just added semantics to basic OpenID transactions. If we could use PDF signatures as legally valid signatures in Estonia, it could be PDF based signatures instead of XAdES, or ODF signatures, or MS .doc signatures. FYI, openid.ee allows a RP to upload a contract (template) which must be agreed with and digitally signed (legally binding signature resulting in an XAdES document with the filled in contract signed by the user with an ID-card and stored on the OP) before the OP starts issuing positive assertions about the given user to the given RP. The contract could be a document of any kind (PDF, JPG, DOC, TXT) and the only thing that is transferred to the RP over AX is a 'secret url' from where the RP can download the signed contract (XAdES container with the possibly PDF contract in it). The actual assurance (that the user has signed the contract the RP has uploaded) comes from out of band agreements/contracts between OP and RP. The AX attribute is just an extra option, if the RP wishes to automatically fetch and store the signed contract somewhere. Basically it is an advanced and legally binding 'I agree with terms and conditions' checkbox built on top of standard OpenID. With legally binding I mean that it is dead simple in the court: Here are the terms and conditions you digitally signed and which you have violated as checking checkboxes and pressing 'continue' is not a legally binding action in Estonia, at least I don't know of any court cases about it. If you need an example use case, think of signing and faxing NDA-s before you can download some simple secret product documentation. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
