Conventions for encoding email-address localparts?

[Douglas Otis]

I am new to this list, and have only quickly reviewed the
specifications.  I may have missed some details.

Are there existing conventions for encoding the local-part of an
email-address to represent a type of local identity?  For example, if
email were adapted to send URIs, perhaps based upon BURL extensions,
then OpenID could be used as a means to ensure the recipient of the
message identifies themselves before the message is revealed.  This
would provide an absolute confirmation of the receipt of the message, as
well as ensuring the message remains confidential.

Perhaps [EMAIL PROTECTED] could become jon_doe._at_.example.com.

This might also help in separating local-part identifies from the
location of the identity server.

-Doug


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

RE: Version 2.0 soon final?

[Granqvist, Hans]

Yes, that's what I meant. Final release as in "done". 
 
Sorry for the confusion . . .




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Pat Patterson
Sent: Monday, March 26, 2007 12:47 PM
To: Dick Hardt
Cc: specs@openid.net
Subject: Re: Version 2.0 soon final?


Here at Sun (and, I guess elsewhere), it means 'First Customer
Ship', but I think we use 'Revenue Release' (RR) instead these days.

Cheers,

Pat

Dick Hardt wrote: 

On 26-Mar-07, at 12:22 PM, Josh Hoyt wrote:

  

On 3/20/07, Granqvist, Hans
<[EMAIL PROTECTED]>   wrote:


OpenID 2.0 has been cooking for quite a
while. When
will 2.0 be FCS?
  

What does FCS [1] mean?

Josh

1. http://en.wikipedia.org/wiki/FCS



Future Combat Systems?

http://en.wikipedia.org/wiki/Future_Combat_Systems

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


-- 
Pat Patterson - [EMAIL PROTECTED]
Federation Architect,
Sun Microsystems, Inc.
http://blogs.sun.com/superpat

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

Re: Version 2.0 soon final?

[Pat Patterson]

Here at Sun (and, I guess elsewhere), it means 'First Customer Ship', 
but I think we use 'Revenue Release' (RR) instead these days.


Cheers,

Pat

Dick Hardt wrote:

On 26-Mar-07, at 12:22 PM, Josh Hoyt wrote:

  

On 3/20/07, Granqvist, Hans <[EMAIL PROTECTED]> wrote:


OpenID 2.0 has been cooking for quite a while. When
will 2.0 be FCS?
  

What does FCS [1] mean?

Josh

1. http://en.wikipedia.org/wiki/FCS



Future Combat Systems?

http://en.wikipedia.org/wiki/Future_Combat_Systems

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


--
Pat Patterson - [EMAIL PROTECTED]
Federation Architect,
Sun Microsystems, Inc.
http://blogs.sun.com/superpat

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

Re: Version 2.0 soon final?

[Dick Hardt]

On 26-Mar-07, at 12:22 PM, Josh Hoyt wrote:

> On 3/20/07, Granqvist, Hans <[EMAIL PROTECTED]> wrote:
>> OpenID 2.0 has been cooking for quite a while. When
>> will 2.0 be FCS?
>
> What does FCS [1] mean?
>
> Josh
>
> 1. http://en.wikipedia.org/wiki/FCS

Future Combat Systems?

http://en.wikipedia.org/wiki/Future_Combat_Systems

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

Re: Version 2.0 soon final?

[Josh Hoyt]

On 3/20/07, Granqvist, Hans <[EMAIL PROTECTED]> wrote:
> OpenID 2.0 has been cooking for quite a while. When
> will 2.0 be FCS?

What does FCS [1] mean?

Josh

1. http://en.wikipedia.org/wiki/FCS
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Attribute Exchange pre-draft 5

[Johnny Bufu]

Hello list!

Since draft_4 [1] we've done some implementation and testing (as well  
as listened to community's suggestions on related issues), and have  
incorporated some changes into a pre-draft-5. Before publishing it I  
would like to see your comments about them or about other features /  
changes that would be useful in AX.


One feature we didn't figure out yet if its benefits would be worth  
the added complexity:
- in a fetch response, distinguish between attributes
that the user didn't *want* to release and the ones
not supported by the OP.

What do you think?


The changes are:

- Added ax.mode parameters to all messages, to unambiguously identify  
the message types; the values are:
fetch_request
fetch_response
store_request
store_response_success
store_response_failure
This allows implementers to decouple the processing of the underlying  
OpenID Auth message and the extension layer.


- Clarified that the required flags are hints about the RP's  
requirements
meant to help the user decide what data to release
should not be enforced by the OP
RPs should perform validation on the data they receive anyhow
same principle for SREG discussed here:
http://openid.net/pipermail/general/2007-March/001874.html


- Clarified that a fetch response parameter MUST be sent for each  
requested attribute, with an empty value if the user did not supply one.
along the lines of the above, so that the RP can fallback to  
alternative data collection methods


- Clarified that extension namespace aliases should be determined  
dynamically by the party composing the message
discussed here: http://openid.net/pipermail/specs/2007-March/ 
001372.html


Thanks,
Johnny


[1] http://openid.net/specs/openid-attribute-exchange-1_0-04.html
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs