Re: [specs-pape] Typo in the PAPE spec?

[Nat]

Examples are not normative, but errata in the sense of "a slip in the  
book" is nice none the less.


There is no official move on the PAPE front right now, but may be in a  
near future.


=...@tokyo via iPhone

On 2009/06/19, at 23:07, Paul Madsen  wrote:


are examples normative? If not, is an errata necessary?

Are there any plans for another PAPE version?

paul

John Bradley wrote:

The normative text is correct.

It was always openid.pape.preferred_auth_level_types form Oct 2008  
when it was added to draft 5.

The bad example crept in in Draft 6 and went unnoticed.

We will need to figure out a process for errata.

Thanks for picking it up.

John B.
On 17-Jun-09, at 1:03 PM, Allen Tom wrote:


Hi All,

In Section 5.1 of the PAPE Spec, there's a request parameter  
defined called

  openid.pape.preferred_auth_level_types

however the example in the same section calls it

  openid.pape.preferred_auth_levels

Which one is it?


Thanks
___
specs-pape mailing list
specs-p...@openid.net
http://openid.net/mailman/listinfo/specs-pape


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


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

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

Re: [OpenID] Signing method for XRD

[Nat Sakimura]

Thanks David,
One of the issue that has been raised was that much of those scripting
languages implementation actually calls C++ library to do the task. This
makes it difficult to deploy it in some hosting and PaaS environment, so
libs written in that scripting language is sought.

If it is not there, then we need to evaluate how easy is it to do that, and
perhaps create a project to make them.

Cheers,

=nat

On Sat, Jun 13, 2009 at 3:01 AM, David Garcia  wrote:

> Hi,
>
> Sure I'll do it, but let me make an in-depth analisis of alternatives
> before pointing to a concrete implementation.
>
> I'll rebrowse sources to make those checks this weekend.
>
> Best regards
>
> David Garcia
>
> El 12/06/2009, a las 19:19, Tatsuki Sakushima  escribió:
>
>
>  Hi David,
>>
>>  I completely agree with you, a single technology for those closely
>>> related protocols would be better than forking. The main advantage using
>>> XMLdSIG is that there are a huge amount of services currently working with
>>> this technology. As far as I know there are mature libs for C, C++, Java,
>>> .net, python, ruby, php .
>>>
>>
>> Can you navigate us to some libraries you have seen especially for those
>> scripting languages, python, ruby, and php? So some of us including me can
>> test them and see how they works. Some forks expertizing XML says XML DSig
>> with exclusive c14n is "easy enough", but many of us haven't seen the real
>> example in scripting languages. And if it is easy or not is somewhat
>> subjective. I think showing examples will facilitate this discussion.
>>
>> Best,
>> Tatsuki
>>
>> Tatsuki Sakushima
>> NRI Pacific - Nomura Research Institute America, Inc.
>>
>> (6/12/09 1:48 AM), David Garcia wrote:
>>
>>> Hi Nat,
>>> I completely agree with you, a single technology for those closely
>>> related protocols would be better than forking. The main advantage using
>>> XMLdSIG is that there are a huge amount of services currently working with
>>> this technology. As far as I know there are mature libs for C, C++, Java,
>>> .net, python, ruby, php .
>>> Those libs are compliant with xmldsig interopt tests so this give us
>>> warranties about their intertoperability. Message sign and verify primitives
>>> are very simple from the point of view of the developer and the only problem
>>> arises when trying to verify the signer certificate (path building,
>>> validation, status validation vs CRL and OCSP...) but several "tricks" could
>>> be made here to keep the process simple.
>>> I'll feel very comfortable about using XMLdSIG because from the point of
>>> view of the increase of complexity it won't be as easy as raw data
>>> processing, but it won't be very painful if we use those sets of libs.
>>> If you want maybe we can create a little project for a proof of concept
>>> and make an interop between 2 different technologies signing and verifying
>>> messages. If so please let me know :).
>>> Best regards
>>> Dave
>>> 2009/6/12 =nat mailto:sakim...@gmail.com>>
>>>   Hi.
>>>   Thanks for your great feedback.
>>>   It is kind of interesting that OpenID side wants the simplest form
>>> while
>>>   in the OAuth list, XML DSig is liked better somehow.
>>>>From the spec point of view, it is better to not to fork as much as
>>>   possible,
>>>   so if we can stick to XML DSig, that's great.
>>>   Now, here is another question then.
>>>   If libraries with decent API becomes available to each language,
>>>   written in that language, and is tested for compatibility to each
>>> other,
>>>   would you be amiable to this constrained form of XML DSig?
>>>   =nat
>>>   On Thu, 11 Jun 2009 16:14:56 +0200, David Garcia
>>>   mailto:david.gar...@tractis.com>>
>>>   wrote:
>>>> Hi Hans,
>>>>
>>>> this project offers a set of wrappers over xmlsec library used on
>>>   many
>>>   c++
>>>> envs. I used it a lot and their equivalent in Java for some years on
>>>> critical production envs and they're very mature.
>>>>
>>>> Dealing with xml data as opaque bits (a simplified xml version of
>>> CMS
>>>> signature containers) instead of interpreting the infoset as
>>> proposed
>>>   will
>>>> be a much simpler approach because it eliminates the need of
&g

Re: [OpenID] Signing method for XRD

[=nat]

Hi. 

Thanks for your great feedback. 

It is kind of interesting that OpenID side wants the simplest form while 
in the OAuth list, XML DSig is liked better somehow. 

>From the spec point of view, it is better to not to fork as much as
possible, 
so if we can stick to XML DSig, that's great. 

Now, here is another question then. 

If libraries with decent API becomes available to each language, 
written in that language, and is tested for compatibility to each other, 
would you be amiable to this constrained form of XML DSig? 

=nat

On Thu, 11 Jun 2009 16:14:56 +0200, David Garcia 
wrote:
> Hi Hans,
> 
> this project offers a set of wrappers over xmlsec library used on many
c++
> envs. I used it a lot and their equivalent in Java for some years on
> critical production envs and they're very mature.
> 
> Dealing with xml data as opaque bits (a simplified xml version of CMS
> signature containers) instead of interpreting the infoset as proposed
will
> be a much simpler approach because it eliminates the need of using c14n
> and
> transform algorithms (not mandatory but recommended on some scenarios).
> 
> Maybe this simpler approach will fit for message exchange.
> 
> Best regards
> 
> Dave Garcia
> 
> 
> 2009/6/11 Hans Granqvist 
> 
>> Perhaps someone from VeriSign (Barry? Gary?) can comment on the
> viability
>> of
>> http://xmlsig.sourceforge.net/
>>
>> Hans
>>
>>
>>
>> On Wed, Jun 10, 2009 at 11:54 PM, John Panzer wrote:
>> > My general impression is that something that requires two pieces of
>> software
>> > to agree on an exact, bit for bit infoset representation of an XML
>> document
>> > in order to get security to work is a poor idea.  I have seen no wide
>> > deployments/usage of DSig in Atom feeds -- despite it being part of
> the
>> spec
>> > -- and many complaints about how it's not possible to get it to work
>> > reliably given the software stacks currently in use.  The difficulties
>> with
>> > canonicalization-for-signing in OAuth implementations have also
>> reinforced
>> > my belief that it's much better to err on the side of the robust and
>> simple.
>> >
>> > Signing a stream of uninterpreted bytes cuts out a whole slew of
> failure
>> > modes, and the ones that remain are debuggable -- the bytes match or
> they
>> > don't, and standard tools can tell you which.  It means it's possible
> to
>> > verify a signature with curl + a command line utility.  These are all
>> very
>> > good things.
>> >
>> > (As a side note, it would also make the content type orthogonal to the
>> > signature code -- this is a good thing.)
>> >
>> > So, +1 for the simplest form of signing that could possibly work.
>> >
>> > -John
>> >
>> >
>> > Johannes Ernst wrote:
>> >
>> > I proposed something I called XML-RSig for similar reasons a few years
>> ago:
>> >
>> http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html
>> >
>> > "RSig" for "Really simple Signature".
>> >
>> > The trouble for OpenID and XRD and so forth is that it is not our core
>> > competency -- and shouldn't be -- to innovate around things that
> really
>> > aren't our business. Signing XML documents isn't our business.
>> >
>> > On the other hand, the people whose business it should be somehow seem
> to
>> be
>> > asleep at the wheel, as the problems are well-known and somehow aren't
>> being
>> > addressed, and haven't for years.
>> >
>> > It seems to me that the best way out of this conundrum is:
>> > 1. to foresee, architecturally, the use of several different ways of
>> > constructing signatures, as the matter clearly isn't settled
>> > 2. to make sure that high-end approaches (like XML-DSIG) work well,
> but
>> > low-end approaches (like XML-RSIG) work just as well
>> > 3. to maintain a best practices document that says "today, choice X is
>> your
>> > best bet, and we say that because based on our market research, X has
> the
>> > highest market share in terms of implementors today."
>> >
>> > As we all know, any problem in computer science can be solved by
> adding a
>> > level of indirection. This may well be one of those cases.
>> >
>> >
>> >
>> >
>> >
>> > Johannes Ernst
>> > NetMesh Inc.
>> >
>> &

OAuth Hybrid and UI ML?

[Nat Sakimura]

Hi.
I just found out that the Mailing list for OAuth Hybrid WG and UI WG are not
listed on http://openid.net/mailman/listinfo/ .
<http://openid.net/mailman/listinfo/>

To make sure equal participation, we should make it possible for people to
find out about them.

Are they established at all? Where is the discussion being conducted right
now?

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] Signing method for XRD

[Nat Sakimura]

Hi John,
Thanks for your input!

=nat

On Thu, Jun 11, 2009 at 3:54 PM, John Panzer  wrote:

>  My general impression is that something that requires two pieces of
> software to agree on an exact, bit for bit infoset representation of an XML
> document in order to get security to work is a poor idea.  I have seen no
> wide deployments/usage of DSig in Atom feeds -- despite it being part of the
> spec -- and many complaints about how it's not possible to get it to work
> reliably given the software stacks currently in use.  The difficulties with
> canonicalization-for-signing in OAuth implementations have also reinforced
> my belief that it's much better to err on the side of the robust and simple.
>
> Signing a stream of uninterpreted bytes cuts out a whole slew of failure
> modes, and the ones that remain are debuggable -- the bytes match or they
> don't, and standard tools can tell you which.  It means it's possible to
> verify a signature with curl + a command line utility.  These are all very
> good things.
>
> (As a side note, it would also make the content type orthogonal to the
> signature code -- this is a good thing.)
>
> So, +1 for the simplest form of signing that could possibly work.
>
> -John
>
>
> Johannes Ernst wrote:
>
> I proposed something I called XML-RSig for similar reasons a few years ago:
>
> http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html
>
> "RSig" for "Really simple Signature".
>
> The trouble for OpenID and XRD and so forth is that it is not our core
> competency -- and shouldn't be -- to innovate around things that really
> aren't our business. Signing XML documents isn't our business.
>
> On the other hand, the people whose business it should be somehow seem to
> be asleep at the wheel, as the problems are well-known and somehow aren't
> being addressed, and haven't for years.
>
> It seems to me that the best way out of this conundrum is:
> 1. to foresee, architecturally, the use of several different ways of
> constructing signatures, as the matter clearly isn't settled
> 2. to make sure that high-end approaches (like XML-DSIG) work well, but
> low-end approaches (like XML-RSIG) work just as well
> 3. to maintain a best practices document that says "today, choice X is your
> best bet, and we say that because based on our market research, X has the
> highest market share in terms of implementors today."
>
> As we all know, any problem in computer science can be solved by adding a
> level of indirection. This may well be one of those cases.
>
>
>
>
>
> Johannes Ernst
> NetMesh Inc.
>
>
> ------
>
>
>
>  --
>
>   http://netmesh.info/jernst
>
>
>
>  --
> ___
> specs mailing listsp...@openid.nethttp://openid.net/mailman/listinfo/specs
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] Signing method for XRD

[Nat Sakimura]

Hi Allen,

Thanks for your input.

What do you think of the proposal on
http://wiki.oasis-open.org/xri/XrdOne/SimpleSign ?
Would it be simple enough? (Well, I do not think it can go any simpler than
that but... ;-).
Would you implement it?

On Thu, Jun 11, 2009 at 1:52 PM, Allen Tom  wrote:

>  Hi Nat,
>
> Generating signatures is tricky, and XMLDSig is trickier than most. That
> being said, there are libraries that do it, and they do seem to work.
>
> First of all, I'd be happier to see something other than XML, but if XML
> has already been decided on, then I would not mind seeing something other
> than XMLDSig, if the alternative is significantly for developers to generate
> than XMLDSig.
>
> Allen
>
> Nat Sakimura wrote:
>
> Hmmm.
>
> Perhaps I did not spell my intent in the original mail well enough.
>
> My question was:
>
> (1) Is XML DSig easy enough for you developers to use?
> (2) Is XML DSig supported in your environemnt?
>e.g., Google AppEngine, Force.com, your hosting environment, your
> own server, etc.
> (3) If either (1) or (2) is negative, are you aimiable to use a very simple
> alternative to it,
>or you do not bother signing XRD at all?
>
> Best,
>
> =nat
>
> On Thu, Jun 11, 2009 at 4:16 AM, Santosh Rajan wrote:
>
>>
>> I agree that in XML they are not equivalent. Yes but the signing process
>> itself is binary, it has nothing to do with text or its meaning.
>>
>>
>> Hans Granqvist wrote:
>> >
>> >> Once you digitally sign a document, though physically the document
>> >> remains
>> >> in tact and retains its content type, after the act of signing, it is
>> >> really
>> >> a frozen bunch of bits. And if you dont make that distinction you get
>> >> into
>> >> all sorts of tangles. And that was the mistake made by XMLDSig. In
>> other
>> >> words after signing the Content-Type should be binary, whatever you
>> want
>> >> to
>> >> call it. After verification it takes up its original Content-Type.
>> >
>> > In XML these two are equivalent:
>> >
>> >
>> >
>> >
>> >
>>  > A signing process needs to understand this, and that is what XML Dsig
>> > does.
>> > XML was not defined to be a wire format.
>> >
>> > Hans
>> > ___
>> > general mailing list
>> > gene...@openid.net
>> > http://openid.net/mailman/listinfo/general
>> >
>> >
>>
>>
>>  -
>>
>> Santosh Rajan
>> http://santrajan.blogspot.com http://santrajan.blogspot.com
>> --
>>  View this message in context:
>> http://www.nabble.com/Signing-method-for-XRD-tp23956678p23969137.html
>> Sent from the OpenID - General mailing list archive at Nabble.com.
>>
>> ___
>>  general mailing list
>> gene...@openid.net
>> http://openid.net/mailman/listinfo/general
>>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
>
> --
> ___
> general mailing 
> listgene...@openid.nethttp://openid.net/mailman/listinfo/general
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] Signing method for XRD

[Nat Sakimura]

When we first started discussing the topic, we started off with something
quite similar (in fact a little more simpler) than RSig.
The flow of our discussion over the last 6 months were like this:

The trait was like this.

1. XRDS has been using SAML constrained version of XML DSig, but nobody
implemented it.
There has to be something wrong in specifying this signature method.
(Also, we know that SAML XML DSig created a lot of compatibility issues
in the field. )
2. We have studied the current XML DSig implementations for script
languages, and
found that in most case, we have to link the C libraries. This is no go
for many hosting
environment, so we decided to make a simple alternative "Simple Sign".
3. We came up with Simple Canonicalization + X.509(RSA-SHA) Signature
method,
which can be implemented widely in many scripting languages.
4. Even this Simple Canonicalization raised an issue of comaptibility, so
decided to do
no Canonicalization at all.
5. This seemed to require a detached signature, but it would not be able to
deal with
sequence of XRDs. (Detached Sig)
6. Thus, we created SignedXRD (SXRD) method so that it can be inline, which
is currently in
  http://wiki.oasis-open.org/xri/XrdOne/SimpleSign

http://www.w3.org/2000/09/xmldsig#rsa-sha1";
certuri="pem file location" data="BASE64 of the payload" />

7. When writing a spec for Detached Sig, it has been found that we are
rewriting a lot of what has been in XML Dsig. Thus, XML Dsig with no
canonicalization was explored.
8. Then, it was argued that SAML core ch.5 version of XML DSig is simple
enough and there are scripting language implementations as well, though they
need
the C Libraries to be linked.
9. We are back to the square ONE. (<= We are here.)

My main concern about XML DSig are as follows:

1. Perception:
   If developers think it is too much, it is not going to be deployed.
2. Performance:
   In Java 6, it is not an issue, but in the past, it seems it has been.
3. Support:
   There are linkable C libraries for script languages, but are they
deployed or
deployable? For example, I do not think that can be deployed on Google
AppEngine Python. (Or is it? Please let me know!)
4. If support is not there, is it easy to write your own?
5. What about the performance then?

etc.

My Concern about Simple Sign only is

1. It is new: do people implement it?

My Concern about supporting both are:

1. Is it going to be too much to ask library writers to support both XML
Dsig and Simple Sign?

As a "ever indecisive" person, I tend to opt for "Both" option, but what do
you guys think of it?

=nat

On Thu, Jun 11, 2009 at 2:01 PM, Johannes Ernst  wrote:

> I proposed something I called XML-RSig for similar reasons a few years ago:
>
> http://netmesh.info/jernst/Technical/really-simple-xml-signatures.html
>
> "RSig" for "Really simple Signature".
>
> The trouble for OpenID and XRD and so forth is that it is not our core
> competency -- and shouldn't be -- to innovate around things that really
> aren't our business. Signing XML documents isn't our business.
>
> On the other hand, the people whose business it should be somehow seem to
> be asleep at the wheel, as the problems are well-known and somehow aren't
> being addressed, and haven't for years.
>
> It seems to me that the best way out of this conundrum is:
> 1. to foresee, architecturally, the use of several different ways of
> constructing signatures, as the matter clearly isn't settled
> 2. to make sure that high-end approaches (like XML-DSIG) work well, but
> low-end approaches (like XML-RSIG) work just as well
> 3. to maintain a best practices document that says "today, choice X is your
> best bet, and we say that because based on our market research, X has the
> highest market share in terms of implementors today."
>
> As we all know, any problem in computer science can be solved by adding a
> level of indirection. This may well be one of those cases.
>
>
>
>
>
> Johannes Ernst
> NetMesh Inc.
>
>
>
>  http://netmesh.info/jernst
>
>
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Contract Exchange WG mailling list is finally up and running

[Nat Sakimura]

Dear OpenIDers:

The mailling list for the approved working group "Contract Exchange" is
finally up.
Mailling list address is specs...@openid.net

To join, subscribe at

http://openid.net/mailman/listinfo/specs-cx

and send contribution agreement to the list and d...@oidf.org.

The contribution agreement can be found at:

http://openid.net/wp-content/uploads/2008/03/paper-contribution-agr-final-clean-20080107.doc

When you first suscribe to the list, you will be registered as "moderated".
That is, your post will not appear until I approve.
Once I find your signed agreement being posted to the list, then, I will
take of this moderation flag
so that you can freely post.

Cheers,

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Identifier for group of individulas

[Nat Sakimura]

Well, I think this just says that the full URI MUST not be reassigned
to different (group of) entities, that the verified identifier will be
always this non-recycled full identifier.

=nat

On Thu, May 14, 2009 at 2:39 AM, Andrew Arnott  wrote:
> From the spec:
>
> 11.5.1.  Identifier Recycling
>
> OpenID Providers with large user bases can use fragments to recycle URL
> Identifiers if it is so desired. When reassigning a URL Identifier to a new
> end user OPs should generate a new, unique fragment part.
>
> The full URL with the fragment part constitutes the Claimed Identifier in
> positive assertions, therefore Relying Parties will distinguish between the
> current and previous owners of the fragment-less URL.
>
> This mechanism allows the (presumably short, memorable) recycled URL
> Identifiers without the fragment to be used by end users at login time and
> by Relying Parties for display purposes.
>
> This smells hugely of the idea that only one user controls an identifier at
> a time.
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - Voltaire
>
>
> On Wed, May 13, 2009 at 10:27 AM, Nat Sakimura  wrote:
>>
>> My interpretation is that the fragment does not necessarily mean a new
>> user, but it just differentiate among different users.
>>
>> =nat
>>
>> On Thu, May 14, 2009 at 2:15 AM, Andrew Arnott 
>> wrote:
>> > Fragments are valid URI parts.  But they are unique in that a web
>> > browser
>> > never sends them to the server.  The OpenID 2.0 spec specifically calls
>> > out
>> > fragments as valid ways that OPs can indicate to RPs that a new user
>> > controls this identifier.
>> >
>> > So in fact that may be a problem.  Multiple users could be asserting
>> > control
>> > of the identifier (minus the fragment).  The OpenID 2.0 spec at least
>> > hints
>> > that OPs will use this generational #fragment to indicate a new user
>> > controls the identifier (identifier recycling).  An RP that sees a new
>> > fragment attached to a claimed_id may assume (perhaps rightly) that the
>> > old
>> > user is now gone and delete settings for the old user.  If the OP
>> > habitually
>> > sticks on random goo to the end of an identifier via its #fragment, then
>> > that interpretation by the RP would not be safe.
>> >
>> > I don't know if others read the spec that way though.
>> > --
>> > Andrew Arnott
>> > "I [may] not agree with what you have to say, but I'll defend to the
>> > death
>> > your right to say it." - Voltaire
>> >
>> >
>> > On Wed, May 13, 2009 at 10:08 AM, Santosh Rajan 
>> > wrote:
>> >>
>> >> I am not sure about fragments. I dont think the fragment falls under
>> >> the
>> >> deifinition of URI. see rfc 3986.
>> >> The group can be indentified within the path part, assuming all members
>> >> of
>> >> the group belong to the same OP and the group is known while issuing
>> >> the
>> >> OpenID. In that case we dont need anything to define at the OpenID
>> >> level.
>> >> Or am i missing something here?
>> >>
>> >> Andrew Arnott wrote:
>> >> >
>> >> > Appending a fragment at least will help the RP distinguish between
>> >> > identifiers. And in the short term it has the merit of not requiring
>> >> > any
>> >> > spec changes.
>> >> >
>> >> > But I still would like to see a group membership claim kept separate
>> >> > from
>> >> > the identity claim, perhaps via the claim discovery I described in
>> >> > the
>> >> > other
>> >> > thread.
>> >> > --
>> >> > Andrew Arnott
>> >> > "I [may] not agree with what you have to say, but I'll defend to the
>> >> > death
>> >> > your right to say it." - Voltaire
>> >> >
>> >> >
>> >> > On Wed, May 13, 2009 at 9:31 AM, Nat Sakimura 
>> >> > wrote:
>> >> >
>> >> >> My previous post on pseudonymous identifier seemed to have kicked
>> >> >> off
>> >> >> interesting but orthogonal discussion of identifier for group of
>> >> >> individuals (like school class, friends, etc.)
>> >> >>
>

Re: Identifier for group of individulas

[Nat Sakimura]

My interpretation is that the fragment does not necessarily mean a new
user, but it just differentiate among different users.

=nat

On Thu, May 14, 2009 at 2:15 AM, Andrew Arnott  wrote:
> Fragments are valid URI parts.  But they are unique in that a web browser
> never sends them to the server.  The OpenID 2.0 spec specifically calls out
> fragments as valid ways that OPs can indicate to RPs that a new user
> controls this identifier.
>
> So in fact that may be a problem.  Multiple users could be asserting control
> of the identifier (minus the fragment).  The OpenID 2.0 spec at least hints
> that OPs will use this generational #fragment to indicate a new user
> controls the identifier (identifier recycling).  An RP that sees a new
> fragment attached to a claimed_id may assume (perhaps rightly) that the old
> user is now gone and delete settings for the old user.  If the OP habitually
> sticks on random goo to the end of an identifier via its #fragment, then
> that interpretation by the RP would not be safe.
>
> I don't know if others read the spec that way though.
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - Voltaire
>
>
> On Wed, May 13, 2009 at 10:08 AM, Santosh Rajan  wrote:
>>
>> I am not sure about fragments. I dont think the fragment falls under the
>> deifinition of URI. see rfc 3986.
>> The group can be indentified within the path part, assuming all members of
>> the group belong to the same OP and the group is known while issuing the
>> OpenID. In that case we dont need anything to define at the OpenID level.
>> Or am i missing something here?
>>
>> Andrew Arnott wrote:
>> >
>> > Appending a fragment at least will help the RP distinguish between
>> > identifiers. And in the short term it has the merit of not requiring any
>> > spec changes.
>> >
>> > But I still would like to see a group membership claim kept separate
>> > from
>> > the identity claim, perhaps via the claim discovery I described in the
>> > other
>> > thread.
>> > --
>> > Andrew Arnott
>> > "I [may] not agree with what you have to say, but I'll defend to the
>> > death
>> > your right to say it." - Voltaire
>> >
>> >
>> > On Wed, May 13, 2009 at 9:31 AM, Nat Sakimura 
>> > wrote:
>> >
>> >> My previous post on pseudonymous identifier seemed to have kicked off
>> >> interesting but orthogonal discussion of identifier for group of
>> >> individuals (like school class, friends, etc.)
>> >>
>> >> Please use this thread instead for this discussion.
>> >>
>> >> Just to put an context to the discussion, I can put one deployed
>> >> example of this type of identifier use.
>> >>
>> >> mixi, the largest Japanese SNS, is using the concept of "group
>> >> identifier."
>> >>
>> >> For example, to prove you are a friend of mine, you can authenticate
>> >> with the identifier
>> >>
>> >> https://id.mixi.jp/nat/friend
>> >>
>> >> The verified identifier would be something like
>> >> https://id.mixi.jp/nat/friend#hashOfYourId etc.,
>> >> if I rememer right.
>> >>
>> >> As you can see, it requires no change in the OpenID AuthN 2.0 nor an
>> >> extension.
>> >>
>> >> Anyways.. my 2c.
>> >>
>> >> =nat
>> >>
>> >> --
>> >> Nat Sakimura (=nat)
>> >> http://www.sakimura.org/en/
>> >> ___
>> >> specs mailing list
>> >> specs@openid.net
>> >> http://openid.net/mailman/listinfo/specs
>> >>
>> >
>> > ___
>> > specs mailing list
>> > specs@openid.net
>> > http://openid.net/mailman/listinfo/specs
>> >
>> >
>>
>>
>> -
>>
>> Santosh Rajan
>> http://santrajan.blogspot.com http://santrajan.blogspot.com
>> --
>> View this message in context:
>> http://www.nabble.com/Identifier-for-group-of-individulas-tp23525446p23526064.html
>> Sent from the OpenID - Specs mailing list archive at Nabble.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
>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Nat Sakimura]

I think RP discovery is needed anyways.

For deciding whether RP wants psudonym for this transaction or not,
I am not sure if RP discovery alone is enough, though.
RP might want non-psudonym for a particular type of transaction.
So, yes, RP's XRD would be able to specify the default behaviour,
but it would also be useful to be able to override it per transaction.

As a matter of fact, I do not strongly feel that we should bake the
psudonym generation
algorithm into the spec. However, thinking concretely would clarify the
requirement to other portions, like what has to be written in the XRD, etc.
so I think it is useful.

To indicate the quality of the identifier and the assertion, we should
utilize PAPE.

=nat

On Thu, May 14, 2009 at 1:28 AM, George Fletcher  wrote:
> I'm perfectly fine with using RP discovery as a mechanism for the RP to
> specify what "policy" it requires. I believe that unsolicited assertions are
> going to become more common, so we need to support it.
>
> What I don't want OpenID to do is specify the actual syntax of the
> pseudonymous identifier. I agree that the RP has to trust the OP (in some
> sense) or make it's own determination that the OP is not honoring the RP's
> wishes and then take some action.
>
> For RP's behind firewalls, it would be nice to allow them some mechanism
> other than RP discovery to assert their requirements, but that should
> preclude the discover option.
>
> Thanks,
> George
>
> Andrew Arnott wrote:
>>
>> leaves out the scenario of unsolicited assertions.A new directed identity
>> value that the RP passes to the OP to indicate it wants a psuedononymous
>> identifier.  Consider this:
>>
>> An OP needs to perform RP discovery (already), and probably does so before
>> sending an unsolicited assertion in order to find out what the assertion
>> receiving URI would be for a given realm.  DNOA does this already.  If that
>> RP's XRDS document included a TypeURI element that had a special
>> psuedononymous-identifier-only-please value the OP could pick up on this,
>> and send the unsolicited assertion using the appropriate type of claimed_id.
>>
>> Likewise, when an RP sends an ordinary directed identity request to an OP,
>> the OP would again notice the RP's XRDS during RP discovery and see what
>> kind of identifier the RP wants and assert accordingly.
>>
>> Yes, some OPs won't honor the RP's wishes, and some OPs don't do RP
>> discovery at all.  Perhaps to help the RP detect whether the OP respected
>> its wishes would be to send a PAPE extension or some other openid.*
>> parameter to say "yes, this is a pseudo- identifier."  RPs have no way to
>> analytically be certain that some identifier is psuedononymous anyway, so
>> ultimately the RP has to trust the OP (whether implicitly or through a white
>> list is up to the RP).
>>
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the death
>> your right to say it." - Voltaire
>>
>>
>> On Wed, May 13, 2009 at 8:44 AM, George Fletcher > <mailto:gffle...@aol.com>> wrote:
>>
>>    I don't think OpenID should specify how pseudonymous identifiers
>>    are generated. That should be up to the OP. But I like the idea of
>>    using a fixed URI as the claimed_id value to specify the behavior
>>    desired by the RP. If, however, we need to grow this to cover
>>    anonymous based identifiers (i.e. the claims based models from
>>    earlier in this thread) then it might make sense to look at a PAPE
>>    extension that covers the type of identifier requested.
>>
>>    Thanks,
>>    George
>>
>>
>>    Nat Sakimura wrote:
>>
>>        Sorry for a slow response. This week is especially busy for me...
>>
>>        I borrowed the notion from Austrian Citizen ID system.
>>        In there, the services are divided into "sectors."
>>        A sector may span several agencies.
>>        They call ID as PIN (Personal Identification Number).
>>
>>        There is a secret PIN (sPIN) which is not used anywhere but in
>>        their SmartCard.
>>        Then, sector sepcific PIN (ssPIN) is calculated in the manner of :
>>
>>        SHA1(sPIN + SectorID)
>>
>>        (Note, there is a bit more details but...)
>>
>>        I have thrown OP secret into it.
>>        To avoid the analytic attack, I agree that it is better to use
>>        individual secret, as some of you
>>        points out.
>>
>>        Regards,
>>
>>    

Identifier for group of individulas

[Nat Sakimura]

My previous post on pseudonymous identifier seemed to have kicked off
interesting but orthogonal discussion of identifier for group of
individuals (like school class, friends, etc.)

Please use this thread instead for this discussion.

Just to put an context to the discussion, I can put one deployed
example of this type of identifier use.

mixi, the largest Japanese SNS, is using the concept of "group identifier."

For example, to prove you are a friend of mine, you can authenticate
with the identifier

https://id.mixi.jp/nat/friend

The verified identifier would be something like
https://id.mixi.jp/nat/friend#hashOfYourId etc.,
if I rememer right.

As you can see, it requires no change in the OpenID AuthN 2.0 nor an extension.

Anyways.. my 2c.

=nat

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Requiring Pseudonymous Identifier

[Nat Sakimura]

On Thu, May 14, 2009 at 12:46 AM, SitG Admin
 wrote:
> Having two simultaneous threads on two closely related lists, with the same
> subject line, can be confusing.

Right.

The original that I raised is what I have explained copule of hours ago.
It is the identifier of the RP Service (which may span multiple domains).
This has impact onto the psudonymous identifier generation.
As I have explained in my previous post, there are some real
requirements for it, esp. in the government sector.

In contrast, identifier for group of individual while interesting is not
directly related to the psudonym issue. So, shall we separate this
topic into another thread with more appropriate subject?

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

Re: Requiring Pseudonymous Identifier

[Nat Sakimura]

Sorry for a slow response. This week is especially busy for me...

I borrowed the notion from Austrian Citizen ID system.
In there, the services are divided into "sectors."
A sector may span several agencies.
They call ID as PIN (Personal Identification Number).

There is a secret PIN (sPIN) which is not used anywhere but in their SmartCard.
Then, sector sepcific PIN (ssPIN) is calculated in the manner of :

SHA1(sPIN + SectorID)

(Note, there is a bit more details but...)

I have thrown OP secret into it.
To avoid the analytic attack, I agree that it is better to use
individual secret, as some of you
points out.

Regards,

=nat

On Tue, May 12, 2009 at 5:55 PM, Dick Hardt  wrote:
>
> On 12-May-09, at 1:36 AM, Nat Sakimura wrote:
>>
>> Reason for using RP's Subject in XRD instead of simply using realm is
>> to allow for something like group identifier.
>
> would you elaborate on the group identifier concept?
>
>>
>>
>> This is just one idea. Downside of this approach
>> is that we need to set up a WG.
>>
>> I am sure there are more ideas. It might be possible to utilize AX
>> so that it will only be a profile that does not require a WG.
>>
>> So shall we start discussing which direction we want to go forward?
>
> sure!
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Most current version of OpenID / OAuth hybrid spec draft?

[Nat Sakimura]

Hi.

Where can I find the most current version of OpenID / OAuth hybrid spec draft?
I would like to look at it to see if I can borrow as much from the
draft for what I am thinking right now.

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Requiring Pseudonymous Identifier

[Nat Sakimura]

Hi.

In many jurisdictions, some regulated entities are not allwoed to store
correlatable identifiers (e.g., Austria, New Zealand).
Under such circumstances, the current OpenID
spec is kind of problematic that there is no defined way of requesting
non-correlatable pseudonymous identifier from the relying party.

One approach would be to utilize the variation on identifier_select.
Instead of sending http://specs.openid.net/auth/2.0/identifier_select,
an RP might send something like
http://specs.openid.net/auth/2.1/non_cor_psudonym etc.
We could utilized RP's XRD as well.

My initial thinking would be to use such an request identifier as above,
and the OP to compute the pseudonym by

SHA256(RP's Subject in XRD + User's Persistent ID + OP Secret).

Reason for using RP's Subject in XRD instead of simply using realm is
to allow for something like group identifier.

This is just one idea. Downside of this approach
is that we need to set up a WG.

I am sure there are more ideas. It might be possible to utilize AX
so that it will only be a profile that does not require a WG.

So shall we start discussing which direction we want to go forward?


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Request to consider creation of the User Interface Work Group

[Nat Sakimura]

Wow, this time, specs council is moving much faster than previously!
That's a very good indication that the process started to work finally.

Not that my opinion matters at this stage since I am not a spec
council member, but, obviously, mine is +1.

=nat

2009/2/23 Brad Fitzpatrick :
> +1
>
> On Fri, Feb 20, 2009 at 3:19 PM, Allen Tom  wrote:
>>
>> Hi Specs Council,
>>
>> Please consider the attached proposal to form the User Interface Work
>> Group.
>> http://wiki.openid.net/OpenID-User-Interface-Work-Group-Proposal
>>
>>
>>   Charter Proposal
>>
>> In accordance with the OpenID Foundation IPR policies and procedures this
>> note proposes the formation of a new working group chartered to produce an
>> OpenID specification. As per Section 4.1 of the Policies, the proposed
>> charter is below (still liable to change during this feedback period).
>>
>> Name
>>
>> OpenID User Interface Working Group
>>
>>
>> Background Information
>>
>> OpenID traditionally requires the Relying Party to redirect the entire
>> browser window to the OpenID Provider for the user to authenticate before
>> redirecting the browser back to the Relying Party. It is believed that the
>> User Experience (UX) could be significantly improved if the authentication
>> flow occurred within a smaller popup window, making the experience less
>> disruptive to the user.
>> Although it is possible for Relying Parties to open a popup window for the
>> user to authenticate at the OpenID Provider using the Provider's default
>> user interface, the overall user experience can be optimized if the OP was
>> aware that its UI was running within a popup. For instance, an OP may want
>> to resize the popup browser window when using the popup interface, but would
>> probably not want to resize the full browser window when using the default
>> redirect interface. Another optimization is that the OP can close the popup,
>> rather than return a negative assertion if the user chooses to cancel the
>> authentication request.
>> Users who begin the OpenID sign in process on a Relying Party in one
>> language and then transition to their OpenID Provider's site in a different
>> language may find the overall experience to be very disruptive. In many
>> cases, the Relying Party may want to pass a language hint to the OpenID
>> Provider to use to display the User Interface to the user, especially if the
>> user is not already authenticated at the OP.
>>
>>
>>
>>
>> Statement of Purpose
>>
>> This workgroup intends to produce a very brief OpenID extension to enable
>> the OpenID Authentication User Interface to be invoked in a standalone popup
>> window, and to allow the Relying Party to request that the user interface be
>> displayed in a particular language.
>>
>>
>>
>>
>> Scope
>>
>> Produce an extension that allows an OpenID Provider to indicate its
>> support of a popup friendly user interface, as opposed to the default user
>> interface optimized for a full browser window. The popup must be in an
>> independent browser window, and must not be framed by the RP.
>>
>>
>> The extension will also define a mechanim for RPs to pass a language hint
>> to the OP to help determine the langange used to display the OpenID
>> Authentication user interface.
>>
>>
>>
>>
>> Out of Scope
>> The content of the user interface other than the language that the
>> interface is displayed in is out of scope.
>>
>>
>>
>>
>> Specifications
>> OpenID User Interface Extension 1.0
>>
>> Anticipated audience
>>
>> All those interested in improving OpenID Usability.
>>
>> Language of business
>>
>> English.
>>
>> Method of work
>>
>> Mailing list discussion. Posting of intermediate drafts in the OpenID
>> Wiki. Virtual conferencing on an ad-hoc basis.
>>
>> Basis for completion of the activity
>>
>> The OpenID User Interface Extension 1.0 final draft is completed.
>>
>> Proposers
>>
>>   * Allen Tom, a...@yahoo-inc.com, Yahoo!
>>   * Brian Ellin, br...@janrain.com, Janrain
>>   * David Recordon, da...@sixapart.com, Six Apart
>>   * Chris Messina, ch...@citizenagency.com, Vidoop/DiSo Project   * Breno
>> de Medeiros, br...@google.com, Google
>>   * Luke Shepard, lshep...@facebook.com, Facebook
>>
>>
>> Initial Editors
>>
>>   * Allen Tom, a...@yahoo-inc.com, Yahoo!
>>   * Breno de Medeiros, br...@google.com, Google
>>
>>
>> ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
>
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID Security

[Nat Sakimura]

Actually, we have previously tested Fortify. As you have stated, it is
not possible to use it without a professional service. It is merely a
tool to assist the security analyst.

=nat

On Fri, Feb 6, 2009 at 5:48 AM, Darren Bounds  wrote:
> I do not believe OWASP presently does any active vulnerability
> analysis. Rather they provide definition around best practices and
> reference material around web application security as well as a small
> set of open source vulnerability analysis and penetration testing
> tools.
>
> With regard to the Fortify link you sent previously; in my experience
> thus far, I have not found a single automated vulnerability analysis
> tool that's worth the price tag or the effort involved in tuning it.
> More often than not they find nothing more than low hanging fruit and
> false positives. Even worse, they often miss ore than they catch,
> resulting in a large number of false negatives. Subsequently any
> 'certification' an automated tool can provide should be taken with a
> grain of salt.
>
> IMO, if a formal security assessment is desirable, it would be much
> more fruitful to engage a reputable 3rd party to perform one manually.
>
>
> Darren
>
> On Thu, Feb 5, 2009 at 3:08 PM, McGovern, James F (HTSC, IT)
>  wrote:
>> If your implementation is 100% open source, then you don't have to worry
>> about licensing as OWASP (http://www.owasp.org) will scan at no cost...
>>
>> ------
>>
>> Message: 1
>> Date: Fri, 6 Feb 2009 01:34:33 +0900
>> From: Nat Sakimura 
>> Subject: Re: OpenID Security
>> To: "McGovern, James F (HTSC, IT)" 
>> Cc: specs@openid.net
>> Message-ID:
>>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Yeah. Fortify is nice. I do not know what would be the licensing terms
>> now, but before, it used to have a "traveling" kind of license that
>> allowed consultants to do the evaluation for the projects of their
>> customers. It might be worthwhile for somebody like OIDF to buy a
>> license and run a certification program out of it. Of course, having
>> secure profile, which we do not have yet, is a prerequisite though.
>>
>> =nat
>>
>> On Wed, Feb 4, 2009 at 11:48 PM, McGovern, James F (HTSC, IT)
>>  wrote:
>>>  OpenID certainly has security features but are all the libraries out
>>> there written to secure coding practices? Wouldn't it be great if all
>>> the library creators could have their code reviewed for security
>>> defects? Check out http://owasp.fortify.com/
>>> 
>>> This communication, including attachments, is for the exclusive use of
>> addressee and may contain proprietary, confidential and/or privileged
>> information.  If you are not the intended recipient, any use, copying,
>> disclosure, dissemination or distribution is strictly prohibited.  If
>> you are not the intended recipient, please notify the sender immediately
>> by return e-mail, delete this communication and destroy all copies.
>>> 
>>>
>>> ___
>>> specs mailing list
>>> specs@openid.net
>>> http://openid.net/mailman/listinfo/specs
>>>
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>>
>>
>> --
>>
>> ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>>
>> End of specs Digest, Vol 30, Issue 7
>> 
>> 
>> This communication, including attachments, is for the exclusive use of 
>> addressee and may contain proprietary, confidential and/or privileged 
>> information.  If you are not the intended recipient, any use, copying, 
>> disclosure, dissemination or distribution is strictly prohibited.  If you 
>> are not the intended recipient, please notify the sender immediately by 
>> return e-mail, delete this communication and destroy all copies.
>> 
>>
>> ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>
>
>
> --
>
> Thank you,
> Darren Bounds
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID Security & certification

[Nat Sakimura]

Yes. I think the protocol testing site idea is already on the table.

=nat

On Fri, Feb 6, 2009 at 7:34 AM, SitG Admin
 wrote:
>> If OIDF wants to certify something, it should certify compliance to the
>> OpenID standard.
>
> +1; different parties employing OpenID might have/practice/need different
> security standards, too (let the first people to want OWASP, submit the
> libraries they're thinking of using to OWASP).
>
> -Shade
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID Security

[Nat Sakimura]

Yeah. Fortify is nice. I do not know what would be the licensing terms
now, but before, it used to have a "traveling" kind of license that
allowed consultants to do the evaluation for the projects of their
customers. It might be worthwhile for somebody like OIDF to buy a
license and run a certification program out of it. Of course, having
secure profile, which we do not have yet, is a prerequisite though.

=nat

On Wed, Feb 4, 2009 at 11:48 PM, McGovern, James F (HTSC, IT)
 wrote:
>  OpenID certainly has security features but are all the libraries out
> there written to secure coding practices? Wouldn't it be great if all
> the library creators could have their code reviewed for security
> defects? Check out http://owasp.fortify.com/
> 
> This communication, including attachments, is for the exclusive use of 
> addressee and may contain proprietary, confidential and/or privileged 
> information.  If you are not the intended recipient, any use, copying, 
> disclosure, dissemination or distribution is strictly prohibited.  If you are 
> not the intended recipient, please notify the sender immediately by return 
> e-mail, delete this communication and destroy all copies.
> 
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Suggested scoping for AX 2.0 WG

[Nat]

CX does not and cannot carry information from multiple users.

The information model deals exclusively around a single subject.

=...@tokyo via iPhone

On 2009/02/04, at 7:50, Dick Hardt  wrote:


Thanks for the feedback Breno!



Nat: can you provide some illumination? I see that CX would define  
attribute types to be carried in AX. I’m confused about the scenario 
 where information from multiple users would be transmitted as that  
implies that the protocol no longer is dealing with a single subject.




-Dick



From: Breno de Medeiros [mailto:br...@google.com]
Sent: Tuesday, February 03, 2009 2:39 PM
To: Dick Hardt
Cc: da...@sixapart.com; Allen Tom; Martin Atkins; Nat Sakimura;  
OpenID Specs Mailing List

Subject: Re: Suggested scoping for AX 2.0 WG





On Tue, Feb 3, 2009 at 2:19 PM, Dick Hardt  
 wrote:


1) I'd prefer to NOT include SREG in the work, but am ok with it  
being in if the scope is really to clarify issues in SREG and add  
language directing people to AX. Anyone else have a strong opinion  
either way? (SREG included in this WG or in a different one?)



I'm ok either way.



2) In the Scope section, I feel strongly that bulk exchange of  
attributes about multiple users is out of scope. It is a very  
different design pattern then what AX does now. I have not seen the  
background on why this is in scope, so perhaps I can have a  
different view if someone cares to enlighten me.



When Nat Sakimura wrote the contract exchange CX proposal, he  
included scope for exchanging validation/metadata about attributes,  
and it was felt that it should belong here. CX also needs this bulk  
exchange functionality and again because it pertained to attributes,  
it was believed that it would better fit here.


The advantage of keeping it in this WG is that we make sure that  
different approaches to handling exchange of user attributes are  
viewed by the same people, even if it ends up in a separate mini-spec.


The counter-argument is that most members of this WG are not  
interested primarily in this functionality, and it may distract both  
efforts (CX and AX), and that AX is unlikely to directly support  
anything along these lines.






-- Dick

PS: please use my microsoft.com address for any specs discussions.




--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Suggested scoping for AX 2.0 WG

[Nat]

=...@tokyo via iPhone

On 2009/02/04, at 7:39, Breno de Medeiros  wrote:




On Tue, Feb 3, 2009 at 2:19 PM, Dick Hardt  
 wrote:
1) I'd prefer to NOT include SREG in the work, but am ok with it  
being in if the scope is really to clarify issues in SREG and add  
language directing people to AX. Anyone else have a strong opinion  
either way? (SREG included in this WG or in a different one?)


I'm ok either way.


2) In the Scope section, I feel strongly that bulk exchange of  
attributes about multiple users is out of scope. It is a very  
different design pattern then what AX does now. I have not seen the  
background on why this is in scope, so perhaps I can have a  
different view if someone cares to enlighten me.


When Nat Sakimura wrote the contract exchange CX proposal, he  
included scope for exchanging validation/metadata about attributes,  
and it was felt that it should belong here. CX also needs this bulk  
exchange functionality and again because it pertained to attributes,  
it was believed that it would better fit here.




To be clear, what I have suggested is not the bulk exchange of  
multiple users. It is the method to treat number of attributes as a  
group that requires some integrity within them. When it comes to CX,  
by design, it does not do multi user exchane either since it requires  
the parties to explicitly sign the contract.


The advantage of keeping it in this WG is that we make sure that  
different approaches to handling exchange of user attributes are  
viewed by the same people, even if it ends up in a separate mini-spec.


The counter-argument is that most members of this WG are not  
interested primarily in this functionality, and it may distract both  
efforts (CX and AX), and that AX is unlikely to directly support  
anything along these lines.





-- Dick

PS: please use my microsoft.com address for any specs discussions.




--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID Mobile Profile?

[Nat Sakimura]

Yes. As far as the protocol flow is concerned, that flow is exactly
what I have suggested in an earlier mail.

By the way, have you thought of some way of dynamically establishing
consumer_key & consumer_secret?

I envision that both consumer and provider advertising its identifier
as  in XRD and associated public key would do the job. Of
course, whether the Service Provider accepts the request is entirely
at their descretion, but it will remove the manual process there.

=nat



On Tue, Feb 3, 2009 at 4:56 AM, Allen Tom  wrote:
> Hi Nat,
>
> OpenID has a huge opportunity in the mobile market, because logging
> in/registering is at least an order of magnitude more painful on a handset
> than on a standard desktop browser. Even with my iPhone, logging in is
> terrible, and I can't think of a single time I've bothered to register.
>
> At least from my perspective, I'm more interested in discussing UX rather
> than protocol changes. Although the URLs are getting really long, the URL
> length is an implementation detail that is mostly hidden from the user.
> Supporting the equivalent of SAML's artifact binding as an additional OpenID
> communication mode isn't really going to improve the UX for users of iPhone
> class devices.
>
> Because OpenID and OAuth appear to be converging, I'd prefer to see
> artifact-type binding implemented using OAuth's Request Token. In OAuth, the
> RP (aka Consumer) first requests a Request Token using direct communication,
> and then redirects the browser to the OP (aka SP) with the Request Token to
> maintain the state. Instead of having the browser pass all the request
> parameters on the URL, all the parameters are represented by the Request
> Token, which is intented to be relatively short.
>
> Allen
>
>
> Nat Sakimura wrote:
>
> Hi.
>
> Are there poeple who are interested in discussing OpenID Mobile profile sort
> of thing?
> Mobile phones has unique challenges of being restricted in URL length etc.
> OpenID as it stands now has very lengthy URLs in both requests and responses
> and it sometimes does not fit into the restrictions.
> SAML world has defined artifact binding to cope with it. IMHO, OpenID should
> define something like that also.
>
> In Japan, there are bunch of people (including mobile carriers) who wants to
> do it.
>
> Are there interest here as well?
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
>
> ____
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID Mobile Profile?

[Nat Sakimura]

:-)

So we shall contiue. =zigorou, who wrote the Japanese presentation that Wil
translated also posted a message to this list, but it apparently has gone
into a moderation queue for some reason... So, here is his text:


Hi.

I'm Toru Yamaguchi (=zigorou).
I'm interested in OpenID for Mobile.

My presentation of OpenID for Mobile(Jp) was translated by wil(=wil).
http://dready.org/blog/2009/01/02/mobile-openid-in-japan/

--

Now, as to the mobile/artifact mode, I kind of feel that it probably is
better to establish a second channel.

So, the flow is like:

1. RP constract a request string as usual (including ones for the various
extensions -- means it could be fairly long.)
2. RP posts this to the OP's artifact mode endpoint published in OP's XRD.
3. OP issues a nonce as an "artifact" or "ticket".
4. RP redirects the browser with this artifact.
5. OP, receiving this artifact, reconstructs the OpenID message from the
post received in step 2 above.
6. Credentail presentation etc. happens as usual, and OP verifies the user's
identity.
7. OP creates a positive response and stores it with the artifact as the
key.
8. OP redirects the browser with the artifact to the RP.
9. RP fetches the response created in 7. and examines it to authorize the
access.

Nice thing about this is that it probalby is going to be a very little code
addition to the current libraries.

The difference between this flow and the SAML artifact binding is that in
case of SAML, the artifact/ticket is created by the RP and OP goes and fetch
the request from RP. I chose this design because RP can be inside the
firewall when OP is on the internet which is a more likely use case  for
OpenID.

=nat

On Sat, Jan 31, 2009 at 3:21 AM, Johannes Ernst  wrote:

> In which case, back to your original question:
>
> Are there poeple who are interested in discussing OpenID Mobile profile
> sort of thing?
>
>
> My answer would be "Yes".
>
>
>
> On Jan 29, 2009, at 22:14, Nat Sakimura wrote:
>
> There are two issues involved.
>
> 1) URL length etc. limitations
> 2) User interface
>
> 1) has impact on 2).
>
> For instance, we want to avoid the users pressing buttons when redirecting.
>
> And, in many cases, we do not have javascript.
> This means we are left with GET and this URL length limitation becomes an
> issue.
>
> 2) cannot be solved globally because it could very well be somewhat
> dependent on
> the carrier implementation and handset capability.
> For most of the phones in Japan, we can get unique
> id for each handset at http level fairly securely so we can depend on it to
>
> avoid any typing (not even username etc.). This was one of the factor why
> m-commerce got so popular in Japan.
>
> In many other markets, e.g., the U.S., this is not granted. Thus, some
> other means
> are required. I know, WIl Tan of Maleysia is working something on iPhone in
> this regard.
> Essentially, it needs to be solved per carrier or per handset class
> (e.g., mid-p enabled phones, etc.), I think.
>
> =nat
>
> On Fri, Jan 30, 2009 at 2:56 PM, Johannes Ernst  netmesh.us> wrote:
>
>> Are you talking about URL length limitations for the identifiers that
>> users need to enter, or for URLs that are being sent around as part of the
>> protocol?
>> IMHO the most important question to ask for mobile devices is: can we do
>> without "typing" anything?
>>
>> On Jan 29, 2009, at 16:56, Nat Sakimura wrote:
>>
>> Hi.
>>
>> Are there poeple who are interested in discussing OpenID Mobile profile
>> sort of thing?
>> Mobile phones has unique challenges of being restricted in URL length etc.
>>
>> OpenID as it stands now has very lengthy URLs in both requests and
>> responses and it sometimes does not fit into the restrictions.
>> SAML world has defined artifact binding to cope with it. IMHO, OpenID
>> should define something like that also.
>>
>> In Japan, there are bunch of people (including mobile carriers) who wants
>> to do it.
>>
>> Are there interest here as well?
>>
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>>  ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID violates Semantic Web (according to them)

[Nat Sakimura]

FYI, it was precisely this reason that XRI 2.0 OASIS votes were shot down by
W3C TAG.
(Besides xri: scheme). The discussion between XRI TC and W3C TAG led to the
conclusion that XRI spec will use 303 (with link header, if needed) instead
of 302 redirect.

=nat

On Fri, Jan 30, 2009 at 3:13 PM, Eran Hammer-Lahav wrote:

> This does not imply anything with regard to my own position on this matter
> but I figured people on this list might find the latest debate [1] over the
> W3C TAG httpRange-14 issue interesting.
>
> Basically according to the httpRange-14 decision, a URI cannot represent
> both a 'person' and an 'information resource' (i.e. a blog). A blog must
> return HTTP 200 while a URI for a person should not, but return a 303
> instead. This is a very important architectural principal of the semantic
> web according to the W3C TAG.
>
> The recent debate is about URIs for relationships (as in the value of a rel
> attribute in a Link header or element). The W3C TAG want the IANA not to
> serve 200 responses for relationship URIs, but 303s. It is a fascinating
> discussion, even if you think it is closer to an episode of Melrose Place
> than a technical accomplishment...
>
> EHL
>
>
> [1] http://lists.w3.org/Archives/Public/www-tag/2009Jan/0114.html
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID Mobile Profile?

[Nat Sakimura]

There are two issues involved.

1) URL length etc. limitations
2) User interface

1) has impact on 2).

For instance, we want to avoid the users pressing buttons when redirecting.
And, in many cases, we do not have javascript.
This means we are left with GET and this URL length limitation becomes an
issue.

2) cannot be solved globally because it could very well be somewhat
dependent on
the carrier implementation and handset capability.
For most of the phones in Japan, we can get unique
id for each handset at http level fairly securely so we can depend on it to
avoid any typing (not even username etc.). This was one of the factor why
m-commerce got so popular in Japan.

In many other markets, e.g., the U.S., this is not granted. Thus, some other
means
are required. I know, WIl Tan of Maleysia is working something on iPhone in
this regard.
Essentially, it needs to be solved per carrier or per handset class
(e.g., mid-p enabled phones, etc.), I think.

=nat

On Fri, Jan 30, 2009 at 2:56 PM, Johannes Ernst  wrote:

> Are you talking about URL length limitations for the identifiers that users
> need to enter, or for URLs that are being sent around as part of the
> protocol?
> IMHO the most important question to ask for mobile devices is: can we do
> without "typing" anything?
>
> On Jan 29, 2009, at 16:56, Nat Sakimura wrote:
>
> Hi.
>
> Are there poeple who are interested in discussing OpenID Mobile profile
> sort of thing?
> Mobile phones has unique challenges of being restricted in URL length etc.
> OpenID as it stands now has very lengthy URLs in both requests and
> responses and it sometimes does not fit into the restrictions.
> SAML world has defined artifact binding to cope with it. IMHO, OpenID
> should define something like that also.
>
> In Japan, there are bunch of people (including mobile carriers) who wants
> to do it.
>
> Are there interest here as well?
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

OpenID Mobile Profile?

[Nat Sakimura]

Hi.

Are there poeple who are interested in discussing OpenID Mobile profile sort
of thing?
Mobile phones has unique challenges of being restricted in URL length etc.
OpenID as it stands now has very lengthy URLs in both requests and responses
and it sometimes does not fit into the restrictions.
SAML world has defined artifact binding to cope with it. IMHO, OpenID should
define something like that also.

In Japan, there are bunch of people (including mobile carriers) who wants to
do it.

Are there interest here as well?

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Request for consideration of AX 2.0 Working Group Charter Proposal

[Nat Sakimura]

+1 Also, having the sunset / expiry of the SREG 1.1 might be a good idea.

When we are doing spec work, it would be a good idea to consider
implementing an incentive for convergence, I suppose.

=nat

On Wed, Jan 28, 2009 at 6:26 PM, Dick Hardt  wrote:

> +1 to a separate WG to fix SREG. Adding language to SREG 1.1 recommending
> AX for new development would clarify for the community the direction. (I'm
> presuming there is consensus on one spec long term and that the
> extensibility of AX is preferred)
>
> -- Dick
>
>
> On 27-Jan-09, at 6:30 PM, Allen Tom wrote:
>
>  I agree with Martin. I believe that AX is the correct solution in the long
>> run, but given that there appears to be more SREG implementations currently
>> in the wild, we should update it to make it useful for sites that want to
>> use it.
>>
>> The other factor is that our lawyers feel very strongly that the user
>> should have the opportunity to read the RP's privacy policy before
>> authorizing any data exchange, and only SREG has the ability to do this
>> automatically. The alternative would be to use OAuth, and require RPs to
>> pre-register with Yahoo and provide their privacy policy and/or agree to a
>> ToS before using our OP.
>>
>> Allen
>>
>> Martin Atkins wrote:
>>
>>>
>>> I agree that having both is not ideal, but I also feel strongly that we
>>> need to have a good SREG 1.1 spec because in practice today there are lots
>>> of SREG implementations and it is important to be able to interoperate with
>>> them even if in the long term we'd like to move to AX.
>>>
>>> This is, incidentally, why I was previously proposing forming an SREG
>>> group whose task is *only* to fix the spec to reflect current practice. This
>>> should encourage SREG interop in the short term while new developments to AX
>>> will encourage a move to AX in the longer term.
>>>
>>>  _______
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Request for consideration of AX 2.0 Working Group Charter Proposal

[Nat Sakimura]

ould also provide
> >> > non-normative guidance on how claims can be validated, which will
> >> > depend on the nature of attribute type as well as claim type.
> >> > * Introduce a new request/response mode which, unlike fetch and
> >> > store, allows for both transmittal of some values and request of
> >> > others. The transmittal not necessarily has the significance of a
> >> > "store" request (could be informative, or for requesting validation).
> >> > * Introduce a direct communication method in both directions
> >> > (OP<->RP), supported via discovery, for bulk exchange of attributes
> >> > about (potentially) multiple users.
> >> >
> >> >
> >> > IV. Specifications
> >> >
> >> > OpenID Attribute Exchange 2.0
> >> >
> >> >
> >> > V. Anticipated audience
> >> >
> >> > All those interested in the obtaining attributes about users
> >> > authenticated via OpenID.
> >> >
> >> >
> >> > VI. Language of business
> >> >
> >> > English.
> >> >
> >> >
> >> > VII. Method of work
> >> >
> >> > Mailing list discussion. Posting of intermediate drafts in the OpenID
> >> > Wiki. Virtual conferencing on an ad-hoc basis.
> >> >
> >> >
> >> > VIII. Basis for completion of the activity
> >> >
> >> > The Attribute Exchange 2.0 spec final draft is delivered and the form
> >> > of management and maintenance of the registry is established.
> >> >
> >> >
> >> > Background Information
> >> > I. Related Work
> >> >
> >> > Attribute Exchange (1.0), and Simple Registration.
> >> > II. Initial Membership
> >> >
> >> > * Tom Allen, a...@yahoo-inc.com. Yahoo! Inc (editor)
> >> > * Mike Graves, mgra...@janrain.com, JanRain, Inc.
> >> > * Dick Hardt, d...@skip.com. Sxip Identity.
> >> > * Breno de Medeiros, br...@google.com. Google, Inc. (editor)
> >> > * Hideki Nara, hd...@ic-tact.co.jp, Tact Communications
> >> > * Nat Sakimura, n-sakim...@nri.co.jp (editor)
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > --Breno
> >> >
> >> > +1 (650) 214-1007 desk
> >> > +1 (408) 212-0135 (Grand Central)
> >> > MTV-41-3 : 383-A
> >> > PST (GMT-8) / PDT(GMT-7)
> >> > ___
> >> > specs mailing list
> >> > specs@openid.net
> >> > 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
> >
> >
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: CX proposal update

[Nat Sakimura]

What entails the "reasonable UI/UX" probably depends on the jurisdiction, so
we let the implimentation decide it. For example, it seems in the U.S., the
agreement shown by clicking the link is acceptable while in Japan, it is not
according to the METI guideline, etc.

Workflow is separate from the UI. Whatever is the appropriate UI in the
jurisdiction, the proof of the consent and the wrokflow (such as, if proxy
signing is done, the proxy agreement must precedes the signing etc.) will
probably stay the same most of the time.

=nat

On Fri, Jan 23, 2009 at 11:03 AM, Allen Tom  wrote:

>  Hi Nat,
>
> How will the WG define workflow and proof of user consent if the charter
> says that UI and UX are out of scope?
>
> Allen
>
>
>
> Nat wrote:
>
> Whether it really is legally binding depends on what jurisdiction you are
> in, but typically there are some minimal set of info that has to be included
> to be considered to be a good one. Namely, sufficiently unique identifiers
> for all the parties involved, term, date, expiry, renewal privision,
> termination clause, jurisdiction, and signatures. Signature sometimes is of
> not the subject but of a proxy agent.
> CX is going to define how these should be represented.
>
>  These "contracts" typically lives long, and there are readability
> requirement as well. (I.e. it should not require a special software to read
> and understand what it means.) Cryptographically, it requires provisioning
> against algorithm getting compromised such as time stamping.
>
>  We also have to define the verification procedure for all the above.
>
>  Then, there is an issue of what entails the reasonable action and
> workflow etc. as a proof of user consent.
>
>  So, in summary, while we intend to use AX (and/or OAuth hybrid) as the
> undelying protocol, it is a little more than merely defining another set of
> attributes.
>
> =...@tokyo via iPhone
>
> On 2009/01/23, at 5:43, Allen Tom  wrote:
>
>  Hi Nat,
>
> Can you define the term "contract"? Is it legally binding? It is just a
> signed set of attributes? Who are the parties involved with signing the
> contract? The RP, OP, and user? Instead of defining a new CX extension,
> would it just be sufficient to define new attributes using AX?
>
> Would it make more sense to use OAuth instead of defining a new OpenID
> extension? OAuth is designed to allow a user to authorize an RP (aka
> Consumer) to access protected resources hosted by the user's OP (aka Service
> Provider). It might make more sense to use the OpenID+OAuth hybrid protocol
> along with an OAuth protected web service to exchange contract information.
>
> Thanks
> Allen
>
>
>
>
> Nat Sakimura wrote:
>
> I have edited the Contract Exchange Proposal on the wiki.
>
> http://wiki.openid.net/Working_Groups%3AContract_Exchange_1
>
> It is substantially shorter and easier to parse, hopefully.
>
> Please discuss.
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
>
> --
>
> ___
> specs mailing listsp...@openid.nethttp://openid.net/mailman/listinfo/specs
>
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: CX proposal update

[Nat]

Whether it really is legally binding depends on what jurisdiction you  
are in, but typically there are some minimal set of info that has to  
be included to be considered to be a good one. Namely, sufficiently  
unique identifiers for all the parties involved, term, date, expiry,  
renewal privision, termination clause, jurisdiction, and signatures.  
Signature sometimes is of not the subject but of a proxy agent.

CX is going to define how these should be represented.

These "contracts" typically lives long, and there are readability  
requirement as well. (I.e. it should not require a special software to  
read and understand what it means.) Cryptographically, it requires  
provisioning against algorithm getting compromised such as time  
stamping.


We also have to define the verification procedure for all the above.

Then, there is an issue of what entails the reasonable action and  
workflow etc. as a proof of user consent.


So, in summary, while we intend to use AX (and/or OAuth hybrid) as the  
undelying protocol, it is a little more than merely defining another  
set of attributes.


=...@tokyo via iPhone

On 2009/01/23, at 5:43, Allen Tom  wrote:


Hi Nat,

Can you define the term "contract"? Is it legally binding? It is  
just a signed set of attributes? Who are the parties involved with  
signing the contract? The RP, OP, and user? Instead of defining a  
new CX extension, would it just be sufficient to define new  
attributes using AX?


Would it make more sense to use OAuth instead of defining a new  
OpenID extension? OAuth is designed to allow a user to authorize an  
RP (aka Consumer) to access protected resources hosted by the user's  
OP (aka Service Provider). It might make more sense to use the OpenID 
+OAuth hybrid protocol along with an OAuth protected web service to  
exchange contract information.


Thanks
Allen




Nat Sakimura wrote:


I have edited the Contract Exchange Proposal on the wiki.

http://wiki.openid.net/Working_Groups%3AContract_Exchange_1

It is substantially shorter and easier to parse, hopefully.

Please discuss.

--
Nat Sakimura (=nat)
http://www.sakimura.org/en/

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



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

CX proposal update

[Nat Sakimura]

I have edited the Contract Exchange Proposal on the wiki.

http://wiki.openid.net/Working_Groups%3AContract_Exchange_1

It is substantially shorter and easier to parse, hopefully.

Please discuss.

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Separation of Discovery from AuthN (was Proposal to form Discovery Working Group)

[Nat Sakimura]

I think so.

=nat

On Sun, Jan 11, 2009 at 8:14 AM, Breno de Medeiros  wrote:

> Well, Eran published a draft of the full XRD discovery standard yesterday.
> That changes things, because puts discovery on much more solid ground. The
> biggest remaining issue to be addressed is on trust/security/signatures but
> there is already substantial progress on that front as well, and we can
> probably expect a similarly mature draft within a few weeks.
>
> Based on these developments, should we consider a commitment to do the
> OpenID discovery spec in time for 2.1? I think it is important to decide
> this early on because it affects decisions about the structure of the AuthN
> spec.
>
>
> On Tue, Jan 6, 2009 at 8:51 AM, Breno de Medeiros wrote:
>
>> Splitting the specification will also make it easier to understand the
>> changes between Yadis-based and XRD-based discovery, since the authN
>> part of the spec is unlikely to change as much.
>>
>> I am in favor of separating the two specifications and create a
>> 2.0-compatible (with language clean-up) version of discovery.
>>
>> 2009/1/6 Nat Sakimura :
>> > But I suppose it is worthwhile to make the spec clearler.
>> > It can be clearer by decomposeing the notion of OP into Discovery
>> Service
>> > and Authentication Service than collectively calling it as "OP". That
>> will
>> > facilitate a better understanding of the strength and weakness of the
>> > protocol as well.
>> >
>> > =nat
>> >
>> > 2009/1/6 Drummond Reed 
>> >>
>> >> Agreed that it makes sense to split it out when the underlying work
>> (XRD
>> >> 1.0) is ready.
>> >>
>> >>
>> >>
>> >> =Drummond
>> >>
>> >>
>> >>
>> >> 
>> >>
>> >> From: David Recordon [mailto:drecor...@sixapart.com]
>> >> Sent: Sunday, January 04, 2009 11:24 PM
>> >> To: Drummond Reed
>> >> Cc: sappe...@gmail.com; 'Nat Sakimura'; 'John Bradley';
>> specs@openid.net
>> >> Subject: Re: Separation of Discovery from AuthN (was Proposal to form
>> >> Discovery Working Group)
>> >>
>> >>
>> >>
>> >> I'd advocate for waiting until all of the discovery work occurring in
>> >> OASIS, IETF, and W3C shakes out before we make changes to how OpenID
>> >> discovery works.  I'd much rather make this sort of change once rather
>> than
>> >> twice.
>> >>
>> >>
>> >>
>> >> --David
>> >>
>> >>
>> >>
>> >> On Jan 4, 2009, at 11:14 PM, Drummond Reed wrote:
>> >>
>> >> I'm just catching up on holiday mail and wanted to add another +1 to
>> >> separation of Discovery from AuthN. The sooner the better…
>> >>
>> >>
>> >>
>> >> =Drummond
>> >>
>> >>
>> >>
>> >> 
>> >>
>> >> From: specs-boun...@openid.net [mailto:specs-boun...@openid.net] On
>> Behalf
>> >> Of David Fuelling
>> >> Sent: Friday, December 26, 2008 8:47 AM
>> >> To: Nat Sakimura
>> >> Cc: John Bradley; specs@openid.net
>> >> Subject: Re: Proposal to form Discovery Working Group
>> >>
>> >>
>> >>
>> >> On Thu, Dec 25, 2008 at 10:56 AM, Nat Sakimura 
>> >> wrote:
>> >>
>> >> 2. Separation of OP into Discovery Service and Authentication Service.
>> >>  In the current terminology, OP spans both Discovery Service and
>> >> Authentication Service.
>> >>  We should be explicit about it.
>> >>
>> >> +1.  I would like to see discovery services separated from OP services
>> >> too.
>> >>
>> >>
>> >> John Bradley wrote:
>> >> > Breno,
>> >> >
>> >> > I agree.  I recommended separating discovery into a separate doc for
>> >> > 2.1.
>> >> >
>> >> > There didn't seem to be support for the idea at the time,  perhaps
>> >> > circumstances have changed and the idea will be accepted now.
>> >> >
>> >> > Regards
>> >> > John Bradley
>> >> > =jbradley
>> >>
>> >>
>> >>
>> >> ___
>> >> specs mailing list
>> >> specs@openid.net
>> >> http://openid.net/mailman/listinfo/specs
>> >>
>> >>
>> >>
>> >> ___
>> >> specs mailing list
>> >> specs@openid.net
>> >> http://openid.net/mailman/listinfo/specs
>> >>
>> >
>> >
>> >
>> > --
>> > Nat Sakimura (=nat)
>> > http://www.sakimura.org/en/
>> >
>> > ___
>> > specs mailing list
>> > specs@openid.net
>> > http://openid.net/mailman/listinfo/specs
>> >
>> >
>>
>>
>>
>> --
>> --Breno
>>
>> +1 (650) 214-1007 desk
>> +1 (408) 212-0135 (Grand Central)
>> MTV-41-3 : 383-A
>> PST (GMT-8) / PDT(GMT-7)
>>
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Separation of Discovery from AuthN (was Proposal to form Discovery Working Group)

[Nat Sakimura]

But I suppose it is worthwhile to make the spec clearler.
It can be clearer by decomposeing the notion of OP into Discovery Service
and Authentication Service than collectively calling it as "OP". That will
facilitate a better understanding of the strength and weakness of the
protocol as well.

=nat

2009/1/6 Drummond Reed 

>  Agreed that it makes sense to split it out when the underlying work (XRD
> 1.0) is ready.
>
>
>
> =Drummond
>
>
>   --
>
> *From:* David Recordon [mailto:drecor...@sixapart.com]
> *Sent:* Sunday, January 04, 2009 11:24 PM
> *To:* Drummond Reed
> *Cc:* sappe...@gmail.com; 'Nat Sakimura'; 'John Bradley'; specs@openid.net
> *Subject:* Re: Separation of Discovery from AuthN (was Proposal to form
> Discovery Working Group)
>
>
>
> I'd advocate for waiting until all of the discovery work occurring in
> OASIS, IETF, and W3C shakes out before we make changes to how OpenID
> discovery works.  I'd much rather make this sort of change once rather than
> twice.
>
>
>
> --David
>
>
>
> On Jan 4, 2009, at 11:14 PM, Drummond Reed wrote:
>
>
>
>I'm just catching up on holiday mail and wanted to add another +1 to
> separation of Discovery from AuthN. The sooner the better…
>
>
>
> =Drummond
>
>
>   ------
>
> *From:* specs-boun...@openid.net 
> [mailto:specs-boun...@openid.net
> ] *On Behalf Of *David Fuelling
> *Sent:* Friday, December 26, 2008 8:47 AM
> *To:* Nat Sakimura
> *Cc:* John Bradley; specs@openid.net
> *Subject:* Re: Proposal to form Discovery Working Group
>
>
>
> On Thu, Dec 25, 2008 at 10:56 AM, Nat Sakimura 
> wrote:
>
>  2. Separation of OP into Discovery Service and Authentication Service.
>  In the current terminology, OP spans both Discovery Service and
> Authentication Service.
>  We should be explicit about it.
>
>
> +1.  I would like to see discovery services separated from OP services too.
>
>
>
>
> John Bradley wrote:
> > Breno,
> >
> > I agree.  I recommended separating discovery into a separate doc for
> > 2.1.
> >
> > There didn't seem to be support for the idea at the time,  perhaps
> > circumstances have changed and the idea will be accepted now.
> >
> > Regards
> > John Bradley
> > =jbradley
>
>
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OIDFSC] FW: Proposal to create the TX working group

[Nat Sakimura]

Hi David,
Since I am in the new years holiday (just when you got back from your
holiday...), I will just comment on a few things inline to supplement Henrik
and Drummond's comments.

On Wed, Dec 31, 2008 at 5:33 PM, David Recordon  wrote:

> Hi Nat,
> I read Josh's email as agreeing with Mike's statement of:
>
>> The OpenID Specifications Council recommends that members reject this
>> proposal to create a working group because the charter is excessively broad,
>> it seems to propose the creation of new mechanisms that unnecessarily create
>> new ways to do accomplish existing tasks, such as digital signatures, and it
>> the proposal is not sufficiently clear on whether it builds upon existing
>> mechanisms such as AX 1.0 in a compatible manner, or whether it requires
>> breaking changes to these underlying protocols.
>
>
I think it is very clear that it builds upon AX. Whether additional message
portion goes into AX 2.0 or CX depends on how AX2.0 (as the AX 2.0 charter
being drafted, it goes in there) evolves.


> While you have clarified that you don't intend to create a new XML
> signature mechanism, OAuth describes a mechanism to use public keys to sign
> these sorts of parameters.  Signatures aside, as Mike said other aspects of
> the charter seem quite broad and it is unclear how it will build upon AX 1.0
> and other underlying existing OpenID technologies.
>

I am expecting OAuth style signature is coming into AuthN 2.1. Then, CX
would use it. OAuth signature per se has to be profiled into OpenID to be
used in OpenID message signing anyways, so just referencing OAuth is not
quite adequate.


>
> Given the draft charter at
> http://wiki.openid.net/Working_Groups%3AContract_Exchange_1:
> 1) The purpose of producing a series of extensions seems too broad.  OpenID
> was born on the idea of doing one simple thing and we've seen success with
> OpenID and related technologies when they are made up of small pieces
> loosely joined.  OpenID Authentication 2.0 broke this rule in some areas and
> we're now seeing the repercussions of doing so.
>

"Series of " is there to allow the possibility of modularization. It might
become clear at a later day when WG work progressed more that it could be
refactored into more than one specification. (For example, I believe that
AuthN 2.0 could have been modularized into Discovery, Assertion format,
Signature, and Messaging protocol, and PAPE could have been into two
modules.) It is hard to know if such modularization is really desirable at
the outset. Thus, I have thrown in the word "series of." Not allowing it
would tend to build a monolithic spec., which is exactly what you are trying
to avoid now.


>
>
> 2) In what jurisdictions are these contracts legally binding?  Is
> "arbitrary parties to create and exchange a mutually-digitally-signed
> legally binding 'contract'" a justifiable statement or should it be toned
> down?  It should also be kept in mind that since OpenID's creation it has
> been very clear that OpenID does not provide trust, but rather trust can be
> built on top of identity.  I'm not saying that OpenID should never deal with
> trust, just trying to understand if this Working Group intends to change how
> OpenID currently does not create this form of trust.
>
> 3) The purpose says that the Working Group intends to possibly extend AX
> and create a series of specifications.
>

 Extending AX actually was what was suggested at IIW with Dick.
Subsequently, it was moved to AX 2.0 WG proposal.
See Out of scope section. It states:

OpenID AX 2.0 was moved out to another WG, which includes the following
pre-requsite for this WG.

   - Request/Response type message "Exchange"
   - Direct Communication method in both direction (OP<->RP)

It does not seem prudent to give a Working Group the ability to arbitrarily
> extend an existing extension or create an unlimited number of
> specifications.
>

It is not. The WG is bound by the scope. The WG may decide to break up its
scoped output into smaller pieces for modularity purpose (that's what is
routinely done in OASIS etc.), but overall output is MUST be TIGHTER than
the scope.



>
> 4) The Scope section is still not clear as to what the Working Group will
> actually be producing.  I would prefer to see the section rewritten, maybe
> mimicking the structure currently being considered for the specification.
>
> As to if you wish to force this proposal forward, I do not believe that it
> currently has sufficient support within the OpenID community to succeed and
> that its broad scope contravenes the community's purpose.  This is why I'm
> really hoping that the proposal can be refined to something which will be
> successful 

Re: Proposal to form Discovery Working Group

[Nat Sakimura]

+1.

Actually, if it is allowed, I am tempted to separate the things into

1. Discovery
2. Assertion Format
3. Signature
4. Protocol

but that probably is too much.

By the way, I've got several things floating in my mind around these.

1. Terminology change
  claimed identifier is a problematic term. It is used both as a user 
supplied identifier and
  OP verified identifier, which may be a bit different (e.g., with 
fragments).
  It was kind of confusing in the first pass.
  I think it would help to define them as user supplied identifier and 
cannonical identifier
  or somehing.

2. Separation of OP into Discovery Service and Authentication Service.
  In the current terminology, OP spans both Discovery Service and 
Authentication Service.
  We should be explicit about it.

3. Change of the point of cannonical identifer generation.
  For URI based OpenID, it is the Authentication Service
  that is generating the cannonical identifier right now.
  This should be changed to Discovery Service so that
   user gains ID portability among Authentication Services.

Regards,

=nat.



John Bradley wrote:
> Breno,
>
> I agree.  I recommended separating discovery into a separate doc for
> 2.1.
>
> There didn't seem to be support for the idea at the time,  perhaps
> circumstances have changed and the idea will be accepted now.
>
> Regards
> John Bradley
> =jbradley
>
>   
>> Message: 2
>> Date: Mon, 22 Dec 2008 11:07:52 -0800
>> From: Breno de Medeiros 
>> Subject: Re: Proposal to form Discovery Working Group
>> To: da...@sixapart.com
>> Cc: Brian Eaton ,  OpenID Specs Mailing List
>>   , Johannes Ernst 
>> Message-ID:
>>   <29fb00360812221107g5cd69346gfcac57575601f...@mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> For the time being, I would be happy if the 2.1 spec moved all the
>> references to discovery to a second document.
>>
>> The first version of the separate document would just "clone" the
>> current approach to discovery in the 2.0 spec. If the updated version
>> that explains XRD discovery is available before the 2.1 WG completes
>> its work, then it could refer to the new document, otherwise it could
>> refer to the old document. In the case of pointing to old document, we
>> probably should add an appendix noting that changes in discovery to
>> support new use cases are coming, and pointers on how to manage the
>> transition.
>>
>>
>>
>> On Mon, Dec 22, 2008 at 10:27 AM, David Recordon > 
>>> wrote:
>>> Agreed with Breno here.  We're going to have to make a change to
>>> OpenID
>>> discovery at some point over the next year as other groups finish
>>> their
>>> evolutions of Yadis, XRDS, etc.  I like this being a separate WG
>>> since it
>>> means that the core Auth spec can choose to move to using it at a
>>> later date
>>> versus being tied up on it's development.
>>>
>>> --David
>>>
>>> On Dec 20, 2008, at 12:48 AM, Breno de Medeiros wrote:
>>>
>>>   
>>>> It is part of the scope of this group to develop a best-practices
>>>> guidance for transition from YADIS to XRD discovery.
>>>>
>>>> Full backward-compatibility is not a goal, since at least one new
>>>> mechanism for publishing discovery information is expected to make
>>>> part of XRD discovery (dynamic mapping type), and this new mechanism
>>>> is being put there (in XRD discovery) in large part because the
>>>> current YADIS mechanism makes it difficult for smaller sites to
>>>> become
>>>> OPs/RPs by using a hosted solution (so it is an OpenID-driven need
>>>> for
>>>> wider adoption).
>>>>
>>>> XRD discovery is also expected to include a signing mechanism, which
>>>> will allow for use of higher-security discovery "profiles".  As part
>>>> of this best-practices document, the OpenID discovery spec should
>>>> give
>>>> guidance on the security characteristics of each profile. The
>>>> current
>>>> mechanism (which limits re-directs and enforces realm authority =
>>>> return_to url authority) will constitute a profile and there will
>>>> likely be at least a second profile that verifies signatures on the
>>>> discovered documents but allow for unmatched realm/return_to URLs.
>>>>
>>>> That being said, we are certainly aware of the need to make the
>>>> transition as smooth as possible, and that is why it is part 

RE: Request for consideration of Working Group Charter Proposal

[Sakimura Nat]

Thank you Martin. Yes, that is my intention.
(And thank you for a better wording as well!)

It also is going to help preocessing (such as signing) a portion of the 
document based on the name space.

=nat


差出人: specs-boun...@openid.net [specs-boun...@openid.net] は Martin Atkins 
[m...@degeneration.co.uk] の代理
送信日時: 2008年12月24日 6:31
CC: OpenID Specs Mailing List
件名: Re: Request for consideration of Working Group Charter Proposal

Allen Tom wrote:
> Hi Nat - I'm not quite sure what you mean by "class".
>

Nat previously talked about the idea of bundling several attributes
together into a single namespace rather than assigning a URL to each
individual scalar attributes. He referred to it as a "class" though you
might instead want to think of it as a "struct".

As I recall (I can't find the original message right now) the propsal
went something like:

ns.blah=http://example.com/some-struct
blah.field1=xyz
blah.field2=abc
blah.field3=123

This way the URL is only included once, making the overall message shorter.

___
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: Request for consideration of Working Group Charter Proposal

[Nat Sakimura]

I noticed a typo. Dick's mail address is not skip.com it is d...@sxip.com.
=nat

On Sat, Dec 20, 2008 at 11:29 AM, Nat Sakimura  wrote:

> +1 but where does the "class" in the earlier post of mine fits into in the
> scope?
>
> On Sat, Dec 20, 2008 at 6:16 AM, Breno de Medeiros wrote:
>
>> siiigh. That is what senility feels like.
>>
>> On Fri, Dec 19, 2008 at 12:39 PM, Allen Tom  wrote:
>> > +1, but I don't know who this Tom Allen is.
>> >
>> > Allen
>> >
>> >
>> > Breno de Medeiros wrote:
>> >>
>> >> Attribute Exchange (1.0), and Simple Registration.
>> >> II. Initial Membership
>> >>
>> >>* Tom Allen, a...@yahoo-inc.com. Yahoo! Inc (editor)
>> >>* Mike Graves, mgra...@janrain.com, JanRain, Inc.
>> >>    * Dick Hardt, d...@skip.com. Sxip Identity.
>> >>* Breno de Medeiros, br...@google.com. Google, Inc. (editor)
>> >>* Hideki Nara, hd...@ic-tact.co.jp, Tact Communications
>> >>* Nat Sakimura, n-sakim...@nri.co.jp (editor)
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>> --
>> --Breno
>>
>> +1 (650) 214-1007 desk
>> +1 (408) 212-0135 (Grand Central)
>> MTV-41-3 : 383-A
>> PST (GMT-8) / PDT(GMT-7)
>> ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Request for consideration of Working Group Charter Proposal

[Nat Sakimura]

+1 but where does the "class" in the earlier post of mine fits into in the
scope?

On Sat, Dec 20, 2008 at 6:16 AM, Breno de Medeiros  wrote:

> siiigh. That is what senility feels like.
>
> On Fri, Dec 19, 2008 at 12:39 PM, Allen Tom  wrote:
> > +1, but I don't know who this Tom Allen is.
> >
> > Allen
> >
> >
> > Breno de Medeiros wrote:
> >>
> >> Attribute Exchange (1.0), and Simple Registration.
> >> II. Initial Membership
> >>
> >>* Tom Allen, a...@yahoo-inc.com. Yahoo! Inc (editor)
> >>* Mike Graves, mgra...@janrain.com, JanRain, Inc.
> >>* Dick Hardt, d...@skip.com. Sxip Identity.
> >>* Breno de Medeiros, br...@google.com. Google, Inc. (editor)
> >>* Hideki Nara, hd...@ic-tact.co.jp, Tact Communications
> >>* Nat Sakimura, n-sakim...@nri.co.jp (editor)
> >>
> >>
> >>
> >>
> >>
> >
> >
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: What is the status of AX 2.0 WG proposal?

[Nat Sakimura]

Added implication is that, by defining "sreg" class, we can effectively roll
sreg into AX.

=nat

On Thu, Dec 18, 2008 at 1:10 PM, Nat Sakimura  wrote:

> P.S. I and Hide Nara was talking the other day that it probably would be
> very useful for the AX to be able to define a "class" of attributes to
> define a set of attributes.
>
> For example, "Creadit Card" class includes following paramters:
> 1. FullName
> 2. Card Number
> 3. Expire Day
> 4. Secure digits
>
> AX parameters like this:
> openid.ns.ax = http://openid.net/srv/ax/2.0
> openid.ax.class.card = http://visa.com/netcard/1.0
> openid.ax.class.card.fullname="Bill Gate"
> openid.ax.class.card.cardnumber = "4312 4324 5353 "
> openid.ax.class.card.expire = "04/10"
> openid.ax.class.card.secure="343"
>
> Without class paremeter:
> openid.ns.ax = http://openid.net/srv/ax/2.0
> opneid.ax.type.fullname= http://visa.com/netcard/1.0/fullname
> opneid.ax.type.cardnumber = http://visa.com/netcard/1.0/cardnumber
> opneid.ax.type.expire = http://visa.com/netcard/1.0/expire
> opneid.ax.type.code= http://visa.com/netcard/1.0/secure
> openid.ax.value.fullname="Bill Gate"
> openid.ax.value.cardnumber = "4312 4324 5353 "
> openid.ax.value.expire = "04/10"
> openid.ax.value.secure="343"
>
> With "class", the message will be shorter, and also will become easier to
> extract a portion of the attributes in a semantically meaningful collection.
> We can even go on and sign over only one class etc.
>
> Could we add something like this to the scope as well?
>
> =nat
>
>
>
> On Thu, Dec 18, 2008 at 1:00 PM, Nat Sakimura  wrote:
>
>> I am looking foward to it!
>>
>>
>> On Thu, Dec 18, 2008 at 12:00 PM, Dick Hardt wrote:
>>
>>> Breno, if you have time to update the proposal per our discussion that
>>> would be fabulous!
>>>
>>>
>>> On 17-Dec-08, at 5:07 PM, Breno de Medeiros wrote:
>>>
>>>  We have made significant process in that in-person chat and we need to
>>>> document this in proposal draft form.
>>>>
>>>> I could try and update the proposal for "validate request" which has
>>>> tentatively been abandoned in terms of allowing meta-data to describe
>>>> attributes in fetch/store requests.
>>>>
>>>> 2008/12/17 Dick Hardt :
>>>>
>>>>> I've been busy with other things. :-)
>>>>> I had an in person chat with Allen Tom, Eran and Breno about what they
>>>>> were
>>>>> thinking of. There was some discussion on the step2 list.
>>>>> I have a work item to write up the scope so that we can get it started
>>>>> --
>>>>> but have needed to deal with some time critical tasks before I could
>>>>> start
>>>>> on it -- sorry.
>>>>> -- Dick
>>>>> On 17-Dec-08, at 4:56 PM, Nat Sakimura wrote:
>>>>>
>>>>> I am very interested in it, but have not heard about it for sometime.
>>>>>
>>>>> What is the status right now?
>>>>>
>>>>> --
>>>>> Nat Sakimura (=nat)
>>>>> http://www.sakimura.org/en/
>>>>> ___
>>>>> specs mailing list
>>>>> specs@openid.net
>>>>> http://openid.net/mailman/listinfo/specs
>>>>>
>>>>>
>>>>> ___
>>>>> specs mailing list
>>>>> specs@openid.net
>>>>> http://openid.net/mailman/listinfo/specs
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> --Breno
>>>>
>>>> +1 (650) 214-1007 desk
>>>> +1 (408) 212-0135 (Grand Central)
>>>> MTV-41-3 : 383-A
>>>> PST (GMT-8) / PDT(GMT-7)
>>>>
>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: What is the status of AX 2.0 WG proposal?

[Nat Sakimura]

P.S. I and Hide Nara was talking the other day that it probably would be
very useful for the AX to be able to define a "class" of attributes to
define a set of attributes.

For example, "Creadit Card" class includes following paramters:
1. FullName
2. Card Number
3. Expire Day
4. Secure digits

AX parameters like this:
openid.ns.ax = http://openid.net/srv/ax/2.0
openid.ax.class.card = http://visa.com/netcard/1.0
openid.ax.class.card.fullname="Bill Gate"
openid.ax.class.card.cardnumber = "4312 4324 5353 "
openid.ax.class.card.expire = "04/10"
openid.ax.class.card.secure="343"

Without class paremeter:
openid.ns.ax = http://openid.net/srv/ax/2.0
opneid.ax.type.fullname= http://visa.com/netcard/1.0/fullname
opneid.ax.type.cardnumber = http://visa.com/netcard/1.0/cardnumber
opneid.ax.type.expire = http://visa.com/netcard/1.0/expire
opneid.ax.type.code= http://visa.com/netcard/1.0/secure
openid.ax.value.fullname="Bill Gate"
openid.ax.value.cardnumber = "4312 4324 5353 "
openid.ax.value.expire = "04/10"
openid.ax.value.secure="343"

With "class", the message will be shorter, and also will become easier to
extract a portion of the attributes in a semantically meaningful collection.
We can even go on and sign over only one class etc.

Could we add something like this to the scope as well?

=nat


On Thu, Dec 18, 2008 at 1:00 PM, Nat Sakimura  wrote:

> I am looking foward to it!
>
>
> On Thu, Dec 18, 2008 at 12:00 PM, Dick Hardt  wrote:
>
>> Breno, if you have time to update the proposal per our discussion that
>> would be fabulous!
>>
>>
>> On 17-Dec-08, at 5:07 PM, Breno de Medeiros wrote:
>>
>>  We have made significant process in that in-person chat and we need to
>>> document this in proposal draft form.
>>>
>>> I could try and update the proposal for "validate request" which has
>>> tentatively been abandoned in terms of allowing meta-data to describe
>>> attributes in fetch/store requests.
>>>
>>> 2008/12/17 Dick Hardt :
>>>
>>>> I've been busy with other things. :-)
>>>> I had an in person chat with Allen Tom, Eran and Breno about what they
>>>> were
>>>> thinking of. There was some discussion on the step2 list.
>>>> I have a work item to write up the scope so that we can get it started
>>>> --
>>>> but have needed to deal with some time critical tasks before I could
>>>> start
>>>> on it -- sorry.
>>>> -- Dick
>>>> On 17-Dec-08, at 4:56 PM, Nat Sakimura wrote:
>>>>
>>>> I am very interested in it, but have not heard about it for sometime.
>>>>
>>>> What is the status right now?
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> http://www.sakimura.org/en/
>>>> _______
>>>> specs mailing list
>>>> specs@openid.net
>>>> http://openid.net/mailman/listinfo/specs
>>>>
>>>>
>>>> ___
>>>> specs mailing list
>>>> specs@openid.net
>>>> http://openid.net/mailman/listinfo/specs
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> --Breno
>>>
>>> +1 (650) 214-1007 desk
>>> +1 (408) 212-0135 (Grand Central)
>>> MTV-41-3 : 383-A
>>> PST (GMT-8) / PDT(GMT-7)
>>>
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Could you update me of the status of CX WG proposal?

[Nat Sakimura]

Thanks Dick!

I am looking forward to hear "Go Ahead!" from the spec council in a very
near future for CX WG.

=nat

On Thu, Dec 18, 2008 at 11:30 AM, Dick Hardt  wrote:

>
> On 17-Dec-08, at 6:17 PM, Nat Sakimura wrote:
>
>  Hi.
>>
>> Could you kindly update me of the status of CX WG proposal?
>> People are waiting for it.
>>
>> Also, I think it is a really good idea to set up a ML for spec council so
>> that people can mail the spec council collectively.
>> I am emailing to David, Dick and Josh just because I happen to have found
>> them easily in my addressbook.
>> I wanted to email to the entire spec council, really.
>>
>
> I thought David was going to create a list for spec council.
>
> Nat: I also cc'ed Mike Jones and Johnny -- the other two members of the
> specs council
>
> -- Dick
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: What is the status of AX 2.0 WG proposal?

[Nat Sakimura]

I am looking foward to it!

On Thu, Dec 18, 2008 at 12:00 PM, Dick Hardt  wrote:

> Breno, if you have time to update the proposal per our discussion that
> would be fabulous!
>
>
> On 17-Dec-08, at 5:07 PM, Breno de Medeiros wrote:
>
>  We have made significant process in that in-person chat and we need to
>> document this in proposal draft form.
>>
>> I could try and update the proposal for "validate request" which has
>> tentatively been abandoned in terms of allowing meta-data to describe
>> attributes in fetch/store requests.
>>
>> 2008/12/17 Dick Hardt :
>>
>>> I've been busy with other things. :-)
>>> I had an in person chat with Allen Tom, Eran and Breno about what they
>>> were
>>> thinking of. There was some discussion on the step2 list.
>>> I have a work item to write up the scope so that we can get it started --
>>> but have needed to deal with some time critical tasks before I could
>>> start
>>> on it -- sorry.
>>> -- Dick
>>> On 17-Dec-08, at 4:56 PM, Nat Sakimura wrote:
>>>
>>> I am very interested in it, but have not heard about it for sometime.
>>>
>>> What is the status right now?
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> http://www.sakimura.org/en/
>>> ___
>>> specs mailing list
>>> specs@openid.net
>>> http://openid.net/mailman/listinfo/specs
>>>
>>>
>>> _______
>>> specs mailing list
>>> specs@openid.net
>>> http://openid.net/mailman/listinfo/specs
>>>
>>>
>>>
>>
>>
>> --
>> --Breno
>>
>> +1 (650) 214-1007 desk
>> +1 (408) 212-0135 (Grand Central)
>> MTV-41-3 : 383-A
>> PST (GMT-8) / PDT(GMT-7)
>>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Could you update me of the status of CX WG proposal?

[Nat Sakimura]

Hi.

Could you kindly update me of the status of CX WG proposal?
People are waiting for it.

Also, I think it is a really good idea to set up a ML for spec council so
that people can mail the spec council collectively.
I am emailing to David, Dick and Josh just because I happen to have found
them easily in my addressbook.
I wanted to email to the entire spec council, really.

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

What is the status of AX 2.0 WG proposal?

[Nat Sakimura]

I am very interested in it, but have not heard about it for sometime.

What is the status right now?

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Please process the WG proposals on the table (WAS The Specs Council and Process)

[Nat Sakimura]

Well. Very good discussion. I am glad that I started the original thread.

At the same time, I would like the spec council to issue overdue
recommendations, especially for Contract Exchange. It has been sitting there
for a long time now. (By now, the actual works should have started.)

As I believe, though the scope may seems a bit wide, the WG scope being
wider than what it really needs to is not a bad thing. WG can always narrow
the scope without any IPR consideration, but it is virtually impossible to
widen the scope afterwards.

=nat
-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: A Working Groups Wiki Page

[Nat Sakimura]

Indeed.

>From the spec works point of view, since a WG can always narrow the scope
but not exand,
it would be better to get it in the scope at the beginning. That's why I
have put it there.

We can always drop it later.

=nat

On Fri, Dec 5, 2008 at 10:14 AM, Breno de Medeiros  wrote:

> On Thu, Dec 4, 2008 at 5:00 PM, Nat Sakimura  wrote:
> > Hi Breno,
> >
> > I am hoping that the core spec will define public key based signature.
> > If it is done, CX is going to use it.
> > Dsig thing in the CX proposal is there just for the sake if it did not
> make
> > it into the core spec because it absolutely is a MUST for CX.
> > (Although, from the modularity point of view, it might be better to
> define
> > dsig separately and reference it from the core spec.)
>
> As long as you are aware of the issue, you can tackle this at a latter
> point by how you structure your deliverables.
>
> >
> > =nat
> >
> >
> > On Fri, Dec 5, 2008 at 2:20 AM, Breno de Medeiros 
> wrote:
> >>
> >> Hi Nat,
> >>
> >> I see that as part of your scope you are discussing an OpenID D-Sign
> >> deliverable. Is this really necessary?
> >>
> >> For instance, the XRD 1.0 spec (which at this point is planned for
> >> incorporation into the OpenID spec by reference) will introduce a
> >> signature scheme for trust purposes. That will mean that a  a D-Sig
> >> algorithm will be part of the core spec.
> >>
> >> There is also some speculation that OpenID will support OAuth style
> >> signatures  (which include a public-key variant) for harmonization. If
> >> that happens there would be _two_ public-key signature schemes as part
> >> of the core spec.
> >>
> >> I understand the public-key signatures is a core requirement for a
> >> trust specification.  But I doubt there is a reason to re-invent such
> >> a scheme. Signature schemes are supposed to be somewhat generic, not
> >> purpose-specific. We should try to specify only a few of them, and
> >> probably the place to do that is the core OpenID spec.
> >>
> >> 2008/12/4 Nat Sakimura :
> >> > Thanks David,
> >> > I have put the CX page onto it.
> >> > Regards,
> >> > =nat
> >> >
> >> > On Thu, Dec 4, 2008 at 4:40 PM, David Recordon <
> drecor...@sixapart.com>
> >> > wrote:
> >> >>
> >> >> We now have a wiki page for Working Groups!
> >> >>  http://wiki.openid.net/Working_Groups
> >> >>
> >> >> I've listed the current PAPE WG as well as the groups that I know
> have
> >> >> been proposed.  I've also filled in the draft charter for the Auth
> 2.1
> >> >> group at http://wiki.openid.net/Working_Groups:Auth_2.1.
> >> >>
> >> >> If you're wanting to see a WG happen, please take this time to fill
> in
> >> >> it's draft charter so that members of this list can review it.  My
> >> >> goal would be to have all four of the proposed groups ready to be
> >> >> voted on by the Foundation Membership during the same period as the
> >> >> Board election -- one week from today -- so that they can all be
> >> >> created within the next two weeks.
> >> >>
> >> >> If you need help writing a charter, I'm happy to help.
> >> >>
> >> >> --David
> >> >>
> >> >> ___
> >> >> specs mailing list
> >> >> specs@openid.net
> >> >> http://openid.net/mailman/listinfo/specs
> >> >
> >> >
> >> >
> >> > --
> >> > Nat Sakimura (=nat)
> >> > http://www.sakimura.org/en/
> >> >
> >> > ___
> >> > specs mailing list
> >> > specs@openid.net
> >> > http://openid.net/mailman/listinfo/specs
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> --Breno
> >>
> >> +1 (650) 214-1007 desk
> >> +1 (408) 212-0135 (Grand Central)
> >> MTV-41-3 : 383-A
> >> PST (GMT-8) / PDT(GMT-7)
> >
> >
> >
> > --
> > Nat Sakimura (=nat)
> > http://www.sakimura.org/en/
> >
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: A Working Groups Wiki Page

[Nat Sakimura]

Hi Breno,

I am hoping that the core spec will define public key based signature.
If it is done, CX is going to use it.
Dsig thing in the CX proposal is there just for the sake if it did not make
it into the core spec because it absolutely is a MUST for CX.
(Although, from the modularity point of view, it might be better to define
dsig separately and reference it from the core spec.)

=nat


On Fri, Dec 5, 2008 at 2:20 AM, Breno de Medeiros <[EMAIL PROTECTED]> wrote:

> Hi Nat,
>
> I see that as part of your scope you are discussing an OpenID D-Sign
> deliverable. Is this really necessary?
>
> For instance, the XRD 1.0 spec (which at this point is planned for
> incorporation into the OpenID spec by reference) will introduce a
> signature scheme for trust purposes. That will mean that a  a D-Sig
> algorithm will be part of the core spec.
>
> There is also some speculation that OpenID will support OAuth style
> signatures  (which include a public-key variant) for harmonization. If
> that happens there would be _two_ public-key signature schemes as part
> of the core spec.
>
> I understand the public-key signatures is a core requirement for a
> trust specification.  But I doubt there is a reason to re-invent such
> a scheme. Signature schemes are supposed to be somewhat generic, not
> purpose-specific. We should try to specify only a few of them, and
> probably the place to do that is the core OpenID spec.
>
> 2008/12/4 Nat Sakimura <[EMAIL PROTECTED]>:
> > Thanks David,
> > I have put the CX page onto it.
> > Regards,
> > =nat
> >
> > On Thu, Dec 4, 2008 at 4:40 PM, David Recordon <[EMAIL PROTECTED]>
> > wrote:
> >>
> >> We now have a wiki page for Working Groups!
> >>  http://wiki.openid.net/Working_Groups
> >>
> >> I've listed the current PAPE WG as well as the groups that I know have
> >> been proposed.  I've also filled in the draft charter for the Auth 2.1
> >> group at http://wiki.openid.net/Working_Groups:Auth_2.1.
> >>
> >> If you're wanting to see a WG happen, please take this time to fill in
> >> it's draft charter so that members of this list can review it.  My
> >> goal would be to have all four of the proposed groups ready to be
> >> voted on by the Foundation Membership during the same period as the
> >> Board election -- one week from today -- so that they can all be
> >> created within the next two weeks.
> >>
> >> If you need help writing a charter, I'm happy to help.
> >>
> >> --David
> >>
> >> ___
> >> specs mailing list
> >> specs@openid.net
> >> http://openid.net/mailman/listinfo/specs
> >
> >
> >
> > --
> > Nat Sakimura (=nat)
> > http://www.sakimura.org/en/
> >
> > ___
> > specs mailing list
> > specs@openid.net
> > http://openid.net/mailman/listinfo/specs
> >
> >
>
>
>
> --
> --Breno
>
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: P&C Insurance Carriers

[Nat Sakimura]

That sounds interesting.

We have some member companies from P&C insurance in OpenID Japan as well, so
I might able to cordinate something with you.

=nat

On Fri, Dec 5, 2008 at 4:31 AM, McGovern, James F (HTSC, IT) <
[EMAIL PROTECTED]> wrote:

> I am attempting to put together a discussion amongst "employees" of P&C
> insurance carriers to discuss scenarios for using OpenID for independent
> insurance agents. Does anyone on this list know of employees at carriers
> that have an understanding at a technical level regarding OpenID?
>
> NOTE: I am not interested in turning this into a vendor lead generation
> mechanism.
> 
> This communication, including attachments, is for the exclusive use of
> addressee and may contain proprietary, confidential and/or privileged
> information.  If you are not the intended recipient, any use, copying,
> disclosure, dissemination or distribution is strictly prohibited.  If you
> are not the intended recipient, please notify the sender immediately by
> return e-mail, delete this communication and destroy all copies.
> 
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: A Working Groups Wiki Page

[Nat Sakimura]

Thanks David,
I have put the CX page onto it.

Regards,

=nat

On Thu, Dec 4, 2008 at 4:40 PM, David Recordon <[EMAIL PROTECTED]>wrote:

> We now have a wiki page for Working Groups!
> http://wiki.openid.net/Working_Groups
>
> I've listed the current PAPE WG as well as the groups that I know have
> been proposed.  I've also filled in the draft charter for the Auth 2.1
> group at http://wiki.openid.net/Working_Groups:Auth_2.1.
>
> If you're wanting to see a WG happen, please take this time to fill in
> it's draft charter so that members of this list can review it.  My
> goal would be to have all four of the proposed groups ready to be
> voted on by the Foundation Membership during the same period as the
> Board election -- one week from today -- so that they can all be
> created within the next two weeks.
>
> If you need help writing a charter, I'm happy to help.
>
> --David
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Proposal to create the TX working group

[Nat Sakimura]

P.S., Nine things in the scope does not correspond to the deliverables. It
merely indicates that these things need to be addressed.
P.P.S. Having stated above, after our evaluation, it boiled down to 4
deliverables.
I have created the wiki page for it. Please refer to it as the most current
version of the charter proposal.
http://wiki.openid.net/Working_Groups:Contract_Exchange_1.0
Hope this one is finally acceptable.

On Thu, Dec 4, 2008 at 10:42 PM, Nat Sakimura <[EMAIL PROTECTED]> wrote:

> I have discussed with Dick at iiw to see if it is possible to build on AX.
> It seems it is inevitable that there needs to be some
> "modifications/extensions" to AX if it is to be done on AX. We at NRI and
> Mike of JanRain have been evaluating what is needed since I submit the last
> version of the charter and we are coming close to the conclusion on what is
> needed. In essence, we need to add another message type apart from fetch and
> store to AX, and we need to define the direct communication in both
> directions (OP->RP and RP->OP). If it is done, we are quite confident that
> we can build the CX on top of AX. In conjunction with it, I have been
> working on XRD SimpleSign that it depends on. We are still working out the
> details, but that probably should be the topic of the WG to follow up.
> I am going to post the amended charter to the Wiki.
>
> Also, I think it is a good practice to formalize the message acceptance
> note issuing procedure (well, the workflow in general) so that there will
> not be a proposal which is not being dealt with.
>
> Regards,
>
> =nat
>
>
> On Thu, Dec 4, 2008 at 4:52 PM, David Recordon <[EMAIL PROTECTED]>wrote:
>
>> Hi Nat,Mike Jones just pointed out that the Steward Council hadn't yet
>> caught this email which I apologize for.
>>
>> I have two concerns with this charter:
>> 1) It appears the WG is going to deliver 9 specifications with a list that
>> isn't clear about what each specification will do and how they relate.  Past
>> approved WG proposals (as well as the current drafts) have had a very clear
>> set of deliverables.
>> 2) While discussed heavily at IIW, this proposal still does not clearly
>> seem build on top of the AX specification.  The current OpenID
>> specifications very clearly fit together and build atop each other and this
>> one should be no different.
>>
>> I'm working on figuring out how to have the Stewards
>> Council recommendation created on a public mailing list, but felt it
>> worthwhile to share my opinions here until that happens.
>>
>> --David
>>
>> On Nov 13, 2008, at 8:40 AM, Nat Sakimura wrote:
>>
>> I was pointed out by Dick that "Key Exchnage" really should be "Key
>> Discovery". I agree. So, I would do s/Key Exchange/Key Discovery/g.
>>
>> Cheers,
>>
>> =nat
>>
>> On Thu, Nov 13, 2008 at 4:02 PM, Nat Sakimura <[EMAIL PROTECTED]> wrote:
>>
>>> Hi.
>>>
>>> Here is the modified version of the charter based on the discussion at
>>> IIW. I chose Contract Exchange instead of Contract Negotiation since
>>> detailed negotiation is out of scope.
>>>
>>> Cheers,
>>>
>>> =nat
>>>
>>> *Contract Exchange WG Charter (formally TX). *
>>>
>>> In accordance with the OpenID Foundation IPR policies and procedures this
>>> note proposes the formation of a new working group chartered to produce an
>>> OpenID specification.  As per Section 4.1 of the Policies, the specifics of
>>> the proposed working group are:
>>>
>>>
>>> *Proposal*:
>>>
>>> (a)  *Charter*.
>>>
>>>  (i)  *WG name*:  Contract Exchange WG (formally Trust Exchange
>>> Extension (TX))
>>>
>>>  (ii)  *Purpose*:  The purpose of this WG is to produce a series of
>>> standard OpenID extension to the OpenID Authentication protocol that enable
>>> s arbitrary parties to create and exchange a mutually-digitally-signed
>>> legally binding "contract" that are  both broadband and mobile friendly
>>> by defining appropriate bindings for each use case.
>>>
>>> For this purpose, (1) public key exchange, (2) signed request and
>>> response based on the public keys, (3) content encryption based on public
>>> key, (4) extensible data transfer method, (5) contract format, (6)
>>> notification methods for asynchronous communications are needed to be
>>> defined. For this purpose, this WG will explorer the possibility of
>>> using/extending OpenID Attribute Ex

Re: Proposal to create the TX working group

[Nat Sakimura]

I have discussed with Dick at iiw to see if it is possible to build on AX.
It seems it is inevitable that there needs to be some
"modifications/extensions" to AX if it is to be done on AX. We at NRI and
Mike of JanRain have been evaluating what is needed since I submit the last
version of the charter and we are coming close to the conclusion on what is
needed. In essence, we need to add another message type apart from fetch and
store to AX, and we need to define the direct communication in both
directions (OP->RP and RP->OP). If it is done, we are quite confident that
we can build the CX on top of AX. In conjunction with it, I have been
working on XRD SimpleSign that it depends on. We are still working out the
details, but that probably should be the topic of the WG to follow up.
I am going to post the amended charter to the Wiki.

Also, I think it is a good practice to formalize the message acceptance note
issuing procedure (well, the workflow in general) so that there will not be
a proposal which is not being dealt with.

Regards,

=nat

On Thu, Dec 4, 2008 at 4:52 PM, David Recordon <[EMAIL PROTECTED]>wrote:

> Hi Nat,Mike Jones just pointed out that the Steward Council hadn't yet
> caught this email which I apologize for.
>
> I have two concerns with this charter:
> 1) It appears the WG is going to deliver 9 specifications with a list that
> isn't clear about what each specification will do and how they relate.  Past
> approved WG proposals (as well as the current drafts) have had a very clear
> set of deliverables.
> 2) While discussed heavily at IIW, this proposal still does not clearly
> seem build on top of the AX specification.  The current OpenID
> specifications very clearly fit together and build atop each other and this
> one should be no different.
>
> I'm working on figuring out how to have the Stewards
> Council recommendation created on a public mailing list, but felt it
> worthwhile to share my opinions here until that happens.
>
> --David
>
> On Nov 13, 2008, at 8:40 AM, Nat Sakimura wrote:
>
> I was pointed out by Dick that "Key Exchnage" really should be "Key
> Discovery". I agree. So, I would do s/Key Exchange/Key Discovery/g.
>
> Cheers,
>
> =nat
>
> On Thu, Nov 13, 2008 at 4:02 PM, Nat Sakimura <[EMAIL PROTECTED]> wrote:
>
>> Hi.
>>
>> Here is the modified version of the charter based on the discussion at
>> IIW. I chose Contract Exchange instead of Contract Negotiation since
>> detailed negotiation is out of scope.
>>
>> Cheers,
>>
>> =nat
>>
>> *Contract Exchange WG Charter (formally TX). *
>>
>> In accordance with the OpenID Foundation IPR policies and procedures this
>> note proposes the formation of a new working group chartered to produce an
>> OpenID specification.  As per Section 4.1 of the Policies, the specifics of
>> the proposed working group are:
>>
>>
>> *Proposal*:
>>
>> (a)  *Charter*.
>>
>>  (i)  *WG name*:  Contract Exchange WG (formally Trust Exchange Extension
>> (TX))
>>
>>  (ii)  *Purpose*:  The purpose of this WG is to produce a series of
>> standard OpenID extension to the OpenID Authentication protocol that enable
>> s arbitrary parties to create and exchange a mutually-digitally-signed
>> legally binding "contract" that are  both broadband and mobile friendly
>> by defining appropriate bindings for each use case.
>>
>> For this purpose, (1) public key exchange, (2) signed request and response
>> based on the public keys, (3) content encryption based on public key, (4)
>> extensible data transfer method, (5) contract format, (6) notification
>> methods for asynchronous communications are needed to be defined. For this
>> purpose, this WG will explorer the possibility of using/extending OpenID
>> Attribute Exchange [AX] as well as defining new extensions where it may fit.
>>
>>
>>
>>  (iii)  *Scope*:
>>
>> Scope of the work
>>
>>-Development of the specifications including:
>>
>>
>>- Public Key Exchange method
>>   - A Public Key Cryptography based digital signature method.
>>   - Legally binding contract format.
>>   - Query/response communication protocols for establishing and
>>   canceling of the contract.
>>   - Message Encryption method to be used for the relevant
>>   communications.
>>   - Notification interface for asynchronous communications.
>>   - Possible extension and profiling of [AX] to accommodate the
>>   above.
>>   - Provisions for long term storage of the contracts.
>>   - Co

Re: PAPE and NIST level policies.

[Nat]

The proposal on the table has generalized NIST thing, I believe.

As to the upstream hint is concerned, I think it is a good idea but it  
was out of scope of the current WG. It belongs to the future spec I  
guess.

[EMAIL PROTECTED] via iPhone

On 2008/11/25, at 18:10, Martin Paljak <[EMAIL PROTECTED]> wrote:

> Hi.
>
> PAPE responses have the ability to send NIST levels used for
> authentication. It would be useful to add these levels as standardized
> request policy URLs to the spec so that the RP could send hints on
> wished authentication strength to the OP.
>
> BTW, why is there a specific nist_auth_level parameter which is
> directly tied to one standards institute yet the 'core' of PAPE,
> policies, don't really define anything except vague 'policies to be
> specified elsewhere' ?
>
>
> -- 
> Martin Paljak
> http://martin.paljak.pri.ee
> +372.515.6495
>
>
>
>
> ___
> 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

[Nat Sakimura]

I was pointed out by Dick that "Key Exchnage" really should be "Key
Discovery". I agree. So, I would do s/Key Exchange/Key Discovery/g.

Cheers,

=nat

On Thu, Nov 13, 2008 at 4:02 PM, Nat Sakimura <[EMAIL PROTECTED]> wrote:

> Hi.
>
> Here is the modified version of the charter based on the discussion at IIW.
> I chose Contract Exchange instead of Contract Negotiation since detailed
> negotiation is out of scope.
>
> Cheers,
>
> =nat
>
> *Contract Exchange WG Charter (formally TX). *
>
> In accordance with the OpenID Foundation IPR policies and procedures this
> note proposes the formation of a new working group chartered to produce an
> OpenID specification.  As per Section 4.1 of the Policies, the specifics of
> the proposed working group are:
>
>
> *Proposal*:
>
> (a)  *Charter*.
>
>  (i)  *WG name*:  Contract Exchange WG (formally Trust Exchange Extension
> (TX))
>
>  (ii)  *Purpose*:  The purpose of this WG is to produce a series of
> standard OpenID extension to the OpenID Authentication protocol that enable
> s arbitrary parties to create and exchange a mutually-digitally-signed
> legally binding "contract" that are  both broadband and mobile friendly by
> defining appropriate bindings for each use case.
>
> For this purpose, (1) public key exchange, (2) signed request and response
> based on the public keys, (3) content encryption based on public key, (4)
> extensible data transfer method, (5) contract format, (6) notification
> methods for asynchronous communications are needed to be defined. For this
> purpose, this WG will explorer the possibility of using/extending OpenID
> Attribute Exchange [AX] as well as defining new extensions where it may fit.
>
>
>
>  (iii)  *Scope*:
>
> Scope of the work
>
>-Development of the specifications including:
>
>
>- Public Key Exchange method
>   - A Public Key Cryptography based digital signature method.
>   - Legally binding contract format.
>   - Query/response communication protocols for establishing and
>   canceling of the contract.
>   - Message Encryption method to be used for the relevant
>   communications.
>   - Notification interface for asynchronous communications.
>   - Possible extension and profiling of [AX] to accommodate the above.
>
>   - Provisions for long term storage of the contracts.
>   - Conformance requirements for other data transfer protocol bindings
>
>
>- Security, threats and Risk analysis
>
>
>- Perform Security Risk analysis and profiles for best practice
>
>  Out of scope
>
>- Term negotiation: Actual negotiation of the terms of a contract
>should be dealt with out-of-band or by other specifications.
>- Assurance programs or other identity governance frameworks.
>- It is the intent that this specification be usable by any trust
>community, whether it uses conventional PKI hierarchies, peer-to-peer trust
>mechanisms, reputation systems, or other forms of trust assurance. The
>specification of any particular trust root, trust hierarchy, or trust 
> policy
>is explicitly out of scope.
>
>
>  (iv)  *Proposed* List of Specifications:  Sries of specs encompassing the
> above requirements. The actual spec may happened to be just an expansion of
> AX or several news specs as it will be determined in the WG. Expected
> completion of the first iteration is in Q1 2009.
>
>  (v)  *Anticipated audience or users of the work*:  Implementers of OpenID
> Providers and Relying Parties, especially those who require security and
> accountability features to exchange sensitive customer information (e.g.
> personally identifiable information and credit card numbers) responsibly
> among trusted parties.
>
>  (vi)  *Language* in which the WG will conduct business:  English.
>
>  (vii)  *Method of work*:  E-mail discussions on the working group mailing
> list, working group conference calls, and possibly face-to-face meetings at
> conferences.
>
>  (viii)  *Basis for determining when the work of the WG is completed*:
> Drafts will be evaluated on the basis of whether they increase or decrease
> consensus within the working group.  The work will be completed once it is
> apparent that maximal consensus on the drafts has been achieved, consistent
> with the purpose and scope.
>
> (b)  *Background Information*.
>
>  (i)  Related work being done by other WGs or organizations:
>
>- OpenID Attribute Exchange Extension 1.0 
> [AX]<http://openid.net/specs/openid-attribute-exchange-1_0.html>
>- LIberty Alliance Identity Governance Framework [IGF] 1.0 
> Draft<http://www.projectliberty.org/l

Re: Proposal to create the TX working group

[Nat Sakimura]

Hi.

Here is the modified version of the charter based on the discussion at IIW.
I chose Contract Exchange instead of Contract Negotiation since detailed
negotiation is out of scope.

Cheers,

=nat

*Contract Exchange WG Charter (formally TX). *

In accordance with the OpenID Foundation IPR policies and procedures this
note proposes the formation of a new working group chartered to produce an
OpenID specification.  As per Section 4.1 of the Policies, the specifics of
the proposed working group are:


*Proposal*:

(a)  *Charter*.

 (i)  *WG name*:  Contract Exchange WG (formally Trust Exchange Extension
(TX))

 (ii)  *Purpose*:  The purpose of this WG is to produce a series of standard
OpenID extension to the OpenID Authentication protocol that
enablesarbitrary parties to create and exchange
a mutually-digitally-signed legally binding "contract" that are  both
broadband and mobile friendly by defining appropriate bindings for each use
case.

For this purpose, (1) public key exchange, (2) signed request and response
based on the public keys, (3) content encryption based on public key, (4)
extensible data transfer method, (5) contract format, (6) notification
methods for asynchronous communications are needed to be defined. For this
purpose, this WG will explorer the possibility of using/extending OpenID
Attribute Exchange [AX] as well as defining new extensions where it may fit.



 (iii)  *Scope*:

Scope of the work

   -Development of the specifications including:


   - Public Key Exchange method
  - A Public Key Cryptography based digital signature method.
  - Legally binding contract format.
  - Query/response communication protocols for establishing and
  canceling of the contract.
  - Message Encryption method to be used for the relevant
  communications.
  - Notification interface for asynchronous communications.
  - Possible extension and profiling of [AX] to accommodate the above.
  - Provisions for long term storage of the contracts.
  - Conformance requirements for other data transfer protocol bindings


   - Security, threats and Risk analysis


   - Perform Security Risk analysis and profiles for best practice

 Out of scope

   - Term negotiation: Actual negotiation of the terms of a contract should
   be dealt with out-of-band or by other specifications.
   - Assurance programs or other identity governance frameworks.
   - It is the intent that this specification be usable by any trust
   community, whether it uses conventional PKI hierarchies, peer-to-peer trust
   mechanisms, reputation systems, or other forms of trust assurance. The
   specification of any particular trust root, trust hierarchy, or trust policy
   is explicitly out of scope.


 (iv)  *Proposed* List of Specifications:  Sries of specs encompassing the
above requirements. The actual spec may happened to be just an expansion of
AX or several news specs as it will be determined in the WG. Expected
completion of the first iteration is in Q1 2009.

 (v)  *Anticipated audience or users of the work*:  Implementers of OpenID
Providers and Relying Parties, especially those who require security and
accountability features to exchange sensitive customer information (e.g.
personally identifiable information and credit card numbers) responsibly
among trusted parties.

 (vi)  *Language* in which the WG will conduct business:  English.

 (vii)  *Method of work*:  E-mail discussions on the working group mailing
list, working group conference calls, and possibly face-to-face meetings at
conferences.

 (viii)  *Basis for determining when the work of the WG is completed*:
Drafts will be evaluated on the basis of whether they increase or decrease
consensus within the working group.  The work will be completed once it is
apparent that maximal consensus on the drafts has been achieved, consistent
with the purpose and scope.

(b)  *Background Information*.

 (i)  Related work being done by other WGs or organizations:

   - OpenID Attribute Exchange Extension 1.0
[AX]<http://openid.net/specs/openid-attribute-exchange-1_0.html>
   - LIberty Alliance Identity Governance Framework [IGF] 1.0
Draft<http://www.projectliberty.org/liberty/content/download/4329/28939/file/liberty-igf-draft-1.0-2008-06-21.zip>
   - *XML Advanced Electronic Signatures [XAdES]*
   - WS-Trust 1.3 [WS-trust]
   <http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.doc>
   - XRI 2.0 [XRI]
   - XDI 1.0 [XDI]
   - Vendor Relationship Management [VRM]


 (ii)  Proposers:

   Drummond Reed, [EMAIL PROTECTED], Cordance/Parity/OASIS (U.S.A)
   Henrik Biering, [EMAIL PROTECTED], Netamia (Denmark)
   Hideki Nara, [EMAIL PROTECTED], Tact Communications (Japan)
   John Bradeley, [EMAIL PROTECTED], OASIS IDTrust Member Section (Canada)
   Mike Graves, [EMAIL PROTECTED], JanRain, Inc. (U.S.A.)
   Nat Sakimura, [EMAIL PROTECTED], Nomura Research Institute,
Ltd.(Japan)
   Robert Ott, [EMAIL PROTECTED], Cla

Re: Proposal to create the TX working group

[Nat Sakimura]

Whether to include these amt.* in it as a generic item or not is what is
needed to be discussed in the WG, I think. I have thrown those in as in most
"contracts" these are needed. (Note: unit does not have to be a monetary
one.) As a summary value, in the actual transactions, they happen to be
pretty useful.

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  XRDS based trusted
discovery + ID-WSF (preferably RESTful version)  rather than OpenID because
it implies that you have SAML processor including XMLEncryption and XMLSig
(which seems to hinder the adoption right now in many scripting language.)
TX as it stands now is trying to avoid this issue by being purely tag-value
based. Also, it is trying to be mobile friendly, which is kind of hard with
AX partly because of its extensibility feature. Having said that, I think it
is important to be able to translate TX message to SAML ro WS-Trust based
messages for the harmonization reason.

Whether it has a future or not is not something a spec writer should
determine, but it is something that the market should determine, IMHO. Is
there an example of AX+SAML deployed and making transaction of monetary
value right now or in the near future? An earlier version of TX is doing
millions of dollars right now and is set to expand in the coming years
(hopefully quite drastically.) You can start guessing by looking at the
member list of OpenID Japan (note: not all of them are in the list. Some of
them are still in process, and some of them would not like to be
identified.) and why some "peculiar" variables are defined in the proposed
TX spec.

=nat

On Sun, Nov 9, 2008 at 4:29 PM, David Recordon <[EMAIL PROTECTED]>wrote:

> After reading the extension a few times, I'm getting caught up in 4.1.6 (
> http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/spec/openid-trust-exchange-1_0.html?root=openidtx#anchor7)<http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/spec/openid-trust-exchange-1_0.html?root=openidtx#anchor7%29>which
>  references amounts being paid, currency, contracts, terms of the
> contract, etc.  Overall, I'm pretty confused about what this extension does
> (it seems to do a lot of different things) which is making it hard for me to
> determine a better name.  I also still feel that the reuse of AX (for it's
> extensibility) combined with the ability to exchange signed SAML tokens is a
> more future proof method and something that will be easier to be widely
> adopted as OpenID continues to evolve.
> --David
>
> On Nov 8, 2008, at 11:14 PM, Drummond Reed wrote:
>
> +1. "OpenID Trust Extension" seems like a good fit.
>
> =Drummond
>
> ------
> *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]<[EMAIL PROTECTED]>
> ] *On Behalf Of *Nat Sakimura
> *Sent:* Saturday, November 08, 2008 12:22 PM
> *To:* [EMAIL PROTECTED]
> *Cc:* specs@openid.net
> *Subject:* Re: Proposal to create the TX working group
>
> Maybe just OpenID Trust Extension just like WS-Trust?
>
> =nat
> On Sun, Nov 9, 2008 at 5:06 AM, Nat Sakimura <[EMAIL PROTECTED]> wrote:
> Hi David,
>
> I do not have any particular attachment to "trust exchange". So, I am ok in
> changing it but it would be nice if I can preserve "TX" acronym though. Do
> you have any specific suggestions?
>
> =nat
>
> On Sun, Nov 9, 2008 at 3:50 AM, David Recordon <[EMAIL PROTECTED]>
> wrote:
> Hi Nat,
> Thanks.  I still would really like to see the name changed for when we
> think about the World-wide market.  Do others disagree?  OpenID Trust
> Exchange just feels like it doesn't actually describe what the spec does nor
> how you can actually exchange "trust".
>
> --David
>
> On Nov 1, 2008, at 2:19 AM, Nat Sakimura wrote:
>
>
> Hi David,
>
> Thanks for your comments. My reply inline below:
>
> 2008/11/1 David Recordon <[EMAIL PROTECTED]>
> Hey Nat,
> Do you see this as being built atop Attribute Exchange for transport or as
> something new that TX defines?  I know Sxip had done work with AX to enable
> passing signed and encrypted attributes using SAML assertions.
>
> I have thought of using AX as transport once, then gave up on it when I was
> thinking of a mobile use case where the amount of payload that could be
> carried with was very limited (URL length in GET is limited to one of
> 128bytes, 256bytes or 512bytes depending on the handset). So, the current
> draft looks a lot like AX with bunch of hard coded attribute types in a
> way.
>
> As far as carrying SAML token etc. in AX are concerned, similar thing has
> also been done by one of the proposer, Robert Ott of Clavid. Martin Paljak
> of Esto

Re: Proposal to create the TX working group

[Nat Sakimura]

Maybe just OpenID Trust Extension just like WS-Trust?
=nat

On Sun, Nov 9, 2008 at 5:06 AM, Nat Sakimura <[EMAIL PROTECTED]> wrote:

> Hi David,
> I do not have any particular attachment to "trust exchange". So, I am ok in
> changing it but it would be nice if I can preserve "TX" acronym though. Do
> you have any specific suggestions?
>
> =nat
>
>
> On Sun, Nov 9, 2008 at 3:50 AM, David Recordon <[EMAIL PROTECTED]>wrote:
>
>> Hi Nat,Thanks.  I still would really like to see the name changed for
>> when we think about the World-wide market.  Do others disagree?  OpenID
>> Trust Exchange just feels like it doesn't actually describe what the spec
>> does nor how you can actually exchange "trust".
>>
>> --David
>>
>> On Nov 1, 2008, at 2:19 AM, Nat Sakimura wrote:
>>
>> Hi David,
>> Thanks for your comments. My reply inline below:
>>
>>
>> 2008/11/1 David Recordon <[EMAIL PROTECTED]>
>>
>>> Hey Nat,Do you see this as being built atop Attribute Exchange for
>>> transport or as something new that TX defines?  I know Sxip had done work
>>> with AX to enable passing signed and encrypted attributes using SAML
>>> assertions.
>>>
>>
>> I have thought of using AX as transport once, then gave up on it when I
>> was thinking of a mobile use case where the amount of payload that could be
>> carried with was very limited (URL length in GET is limited to one of
>> 128bytes, 256bytes or 512bytes depending on the handset). So, the current
>> draft looks a lot like AX with bunch of hard coded attribute types in a
>> way.
>>
>> As far as carrying SAML token etc. in AX are concerned, similar thing has
>> also been done by one of the proposer, Robert Ott of Clavid. Martin Paljak
>> of Estonia (openid.ee) has been using XAdES with AX.
>> These approach are valid. However, I thought the approach partly defeats
>> the purpose of OpenID.
>> If we were using SAML, then we could have used it through out.
>> I wanted to make it easier for the developers by sticking to the tag-value
>> approach.
>> This made us define some of the attribute types defined in SAML and XAdES
>> to be defined as tag-value tag.
>>
>>
>>
>>>
>>> Is "Trust Exchange" really the best name?  Seems like "trust" is quite a
>>> broad concept so something more specific might be better.
>>>
>>
>> Right. Naming was a bit problematic. I started using "Trust" because the
>> messaging model is not dis-similar to WS-Trust. Now, the "trust" defined in
>> WS-Trust in our context is essentially "Contract". So I thought of changing
>> it to "CX" or something, but then, at least in Japan, quite a few key people
>> were already exposed to "TX" by now and thus I kept the name "TX".
>>
>>
>>
>>> --David
>>>
>>> On Oct 31, 2008, at 4:21 AM, Nat Sakimura wrote:
>>>
>>>  Dear Specification Council members:
>>>
>>> In accordance with the OpenID Foundation IPR policies and 
>>> procedures<http://openid.net/foundation/intellectual-property/>this note 
>>> proposes the formation of a new working group chartered to produce
>>> an OpenID specification.  As per Section 4.1 of the Policies, the specifics
>>> of the proposed working group are:
>>> **
>>>  *Trust Exchange (TX) Extension WG Charter*
>>>
>>> In accordance with the OpenID Foundation IPR policies and procedures this
>>> note proposes the formation of a new working group chartered to produce an
>>> OpenID specification.  As per Section 4.1 of the Policies, the specifics of
>>> the proposed working group are:
>>>
>>>
>>> Proposal:
>>>
>>> (a)  Charter.
>>>
>>>  (i)  WG name:  Trust Exchange Extension (TX)
>>>
>>>  (ii)  Purpose:  The purpose of this WG is to produce a standard OpenID
>>> extension to the OpenID Authentication protocol that enables arbitrary
>>> parties to create and exchange a mutually-digitally-signed legally
>>> binding "contract". This protocol extension aims to be both broadband and
>>> mobile friendly by defining appropriate bindings for each use case.
>>>
>>> Although this specification defines one default protocol for transfering
>>> data based on the contract, the data transfer portion is intended to be
>>> pluggable so that other protocols may also be used for this purpose

Re: Proposal to create the TX working group

[Nat Sakimura]

Hi David,
I do not have any particular attachment to "trust exchange". So, I am ok in
changing it but it would be nice if I can preserve "TX" acronym though. Do
you have any specific suggestions?

=nat

On Sun, Nov 9, 2008 at 3:50 AM, David Recordon <[EMAIL PROTECTED]>wrote:

> Hi Nat,Thanks.  I still would really like to see the name changed for when
> we think about the World-wide market.  Do others disagree?  OpenID Trust
> Exchange just feels like it doesn't actually describe what the spec does nor
> how you can actually exchange "trust".
>
> --David
>
> On Nov 1, 2008, at 2:19 AM, Nat Sakimura wrote:
>
> Hi David,
> Thanks for your comments. My reply inline below:
>
>
> 2008/11/1 David Recordon <[EMAIL PROTECTED]>
>
>> Hey Nat,Do you see this as being built atop Attribute Exchange for
>> transport or as something new that TX defines?  I know Sxip had done work
>> with AX to enable passing signed and encrypted attributes using SAML
>> assertions.
>>
>
> I have thought of using AX as transport once, then gave up on it when I was
> thinking of a mobile use case where the amount of payload that could be
> carried with was very limited (URL length in GET is limited to one of
> 128bytes, 256bytes or 512bytes depending on the handset). So, the current
> draft looks a lot like AX with bunch of hard coded attribute types in a
> way.
>
> As far as carrying SAML token etc. in AX are concerned, similar thing has
> also been done by one of the proposer, Robert Ott of Clavid. Martin Paljak
> of Estonia (openid.ee) has been using XAdES with AX.
> These approach are valid. However, I thought the approach partly defeats
> the purpose of OpenID.
> If we were using SAML, then we could have used it through out.
> I wanted to make it easier for the developers by sticking to the tag-value
> approach.
> This made us define some of the attribute types defined in SAML and XAdES
> to be defined as tag-value tag.
>
>
>
>>
>> Is "Trust Exchange" really the best name?  Seems like "trust" is quite a
>> broad concept so something more specific might be better.
>>
>
> Right. Naming was a bit problematic. I started using "Trust" because the
> messaging model is not dis-similar to WS-Trust. Now, the "trust" defined in
> WS-Trust in our context is essentially "Contract". So I thought of changing
> it to "CX" or something, but then, at least in Japan, quite a few key people
> were already exposed to "TX" by now and thus I kept the name "TX".
>
>
>
>> --David
>>
>> On Oct 31, 2008, at 4:21 AM, Nat Sakimura wrote:
>>
>>  Dear Specification Council members:
>>
>> In accordance with the OpenID Foundation IPR policies and 
>> procedures<http://openid.net/foundation/intellectual-property/>this note 
>> proposes the formation of a new working group chartered to produce
>> an OpenID specification.  As per Section 4.1 of the Policies, the specifics
>> of the proposed working group are:
>> **
>>  *Trust Exchange (TX) Extension WG Charter*
>>
>> In accordance with the OpenID Foundation IPR policies and procedures this
>> note proposes the formation of a new working group chartered to produce an
>> OpenID specification.  As per Section 4.1 of the Policies, the specifics of
>> the proposed working group are:
>>
>>
>> Proposal:
>>
>> (a)  Charter.
>>
>>  (i)  WG name:  Trust Exchange Extension (TX)
>>
>>  (ii)  Purpose:  The purpose of this WG is to produce a standard OpenID
>> extension to the OpenID Authentication protocol that enables arbitrary
>> parties to create and exchange a mutually-digitally-signed legally
>> binding "contract". This protocol extension aims to be both broadband and
>> mobile friendly by defining appropriate bindings for each use case.
>>
>> Although this specification defines one default protocol for transfering
>> data based on the contract, the data transfer portion is intended to be
>> pluggable so that other protocols may also be used for this purpose.
>>
>> The extension is not intended to be a general method for defining
>> attributes; the scope is limited to a specific set of attributes necessary
>> for contract semantics. The extension will also define a contract signature
>> based on public key cryptography. When used with a digital certificate
>> signed by a third party, the contract and signature can be used as an
>> assertion of conformance to an applicable assurance program.
>>
>>  (iii)  Scope:
>>
>> Scope of the

Re: Proposal to create the TX working group

[Nat Sakimura]

Hi Santosh,

Welcome!

The spec committee will be giving out advisory within two weeks.

Then, WG is going to be formed, I think.
(Would there be a member voting for creating a WG? > the board. 
Hopefully not.)

To join WG, you need to submit IPR agreement, but that's about it.

There will be a ML setup for discussion.

I am hoping that we can do some face to face at iiw2008b as well.

Regards,

=nat



santosh subramanian wrote:
> Hi Nat,
>
> We have been working on a similar problem. We would also like to be a 
> part of the working group. How do we go about it ?
>
> Thanks,
> Santosh Subramanian
> Shishir  Randive
> Rob Johnson
>
> 2008/11/1 Nat Sakimura <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
>
> Hi David, 
>
> Thanks for your comments. My reply inline below: 
>
>
> 2008/11/1 David Recordon <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>>
>
> Hey Nat,
> Do you see this as being built atop Attribute Exchange for
> transport or as something new that TX defines?  I know Sxip
> had done work with AX to enable passing signed and encrypted
> attributes using SAML assertions.
>
>
> I have thought of using AX as transport once, then gave up on it
> when I was thinking of a mobile use case where the amount of
> payload that could be carried with was very limited (URL length in
> GET is limited to one of 128bytes, 256bytes or 512bytes depending
> on the handset). So, the current draft looks a lot like AX with
> bunch of hard coded attribute types in a way. 
>
> As far as carrying SAML token etc. in AX are concerned, similar
> thing has also been done by one of the proposer, Robert Ott of
> Clavid. Martin Paljak of Estonia (openid.ee <http://openid.ee>)
> has been using XAdES with AX. 
> These approach are valid. However, I thought the approach partly
> defeats the purpose of OpenID. 
> If we were using SAML, then we could have used it through out. 
> I wanted to make it easier for the developers by sticking to the
> tag-value approach. 
> This made us define some of the attribute types defined in SAML
> and XAdES to be defined as tag-value tag. 
>
>   
>
>
> Is "Trust Exchange" really the best name?  Seems like "trust"
> is quite a broad concept so something more specific might be
> better.
>
>
> Right. Naming was a bit problematic. I started using "Trust"
> because the messaging model is not dis-similar to WS-Trust. Now,
> the "trust" defined in WS-Trust in our context is essentially
> "Contract". So I thought of changing it to "CX" or something, but
> then, at least in Japan, quite a few key people were already
> exposed to "TX" by now and thus I kept the name "TX". 
>
>
>
> --David
>
> On Oct 31, 2008, at 4:21 AM, Nat Sakimura wrote:
>
>> Dear Specification Council members:
>>
>> In accordance with the OpenID Foundation IPR policies and
>> procedures
>> <http://openid.net/foundation/intellectual-property/> this
>> note proposes the formation of a new working group chartered
>> to produce an OpenID specification.  As per Section 4.1 of
>> the Policies, the specifics of the proposed working group are:
>> **
>>
>>
>>
>>   *Trust Exchange (TX) Extension WG Charter*
>>
>> In accordance with the OpenID Foundation IPR policies and
>> procedures this note proposes the formation of a new working
>> group chartered to produce an OpenID specification.  As per
>> Section 4.1 of the Policies, the specifics of the proposed
>> working group are:
>>
>>
>> Proposal:
>>
>> (a)  Charter.
>>
>>  (i)  WG name:  Trust Exchange Extension (TX)
>>
>>  (ii)  Purpose:  The purpose of this WG is to produce a
>> standard OpenID extension to the OpenID Authentication
>> protocol that enables arbitrary parties to create and
>> exchange a mutually-digitally-signed legally binding
>> "contract". This protocol extension aims to be both broadband
>> and mobile friendly by defining appropriate bindings for each
>> use case. 
>>
>> Although this specification defines one default protocol for
>> transfering data based on the contract, the data transfer
>> portion is intended to

Re: Proposal to create the TX working group

[Nat Sakimura]

Hi David,
Thanks for your comments. My reply inline below:


2008/11/1 David Recordon <[EMAIL PROTECTED]>

> Hey Nat,Do you see this as being built atop Attribute Exchange for
> transport or as something new that TX defines?  I know Sxip had done work
> with AX to enable passing signed and encrypted attributes using SAML
> assertions.
>

I have thought of using AX as transport once, then gave up on it when I was
thinking of a mobile use case where the amount of payload that could be
carried with was very limited (URL length in GET is limited to one of
128bytes, 256bytes or 512bytes depending on the handset). So, the current
draft looks a lot like AX with bunch of hard coded attribute types in a
way.

As far as carrying SAML token etc. in AX are concerned, similar thing has
also been done by one of the proposer, Robert Ott of Clavid. Martin Paljak
of Estonia (openid.ee) has been using XAdES with AX.
These approach are valid. However, I thought the approach partly defeats the
purpose of OpenID.
If we were using SAML, then we could have used it through out.
I wanted to make it easier for the developers by sticking to the tag-value
approach.
This made us define some of the attribute types defined in SAML and XAdES to
be defined as tag-value tag.



>
> Is "Trust Exchange" really the best name?  Seems like "trust" is quite a
> broad concept so something more specific might be better.
>

Right. Naming was a bit problematic. I started using "Trust" because the
messaging model is not dis-similar to WS-Trust. Now, the "trust" defined in
WS-Trust in our context is essentially "Contract". So I thought of changing
it to "CX" or something, but then, at least in Japan, quite a few key people
were already exposed to "TX" by now and thus I kept the name "TX".



> --David
>
> On Oct 31, 2008, at 4:21 AM, Nat Sakimura wrote:
>
>  Dear Specification Council members:
>
> In accordance with the OpenID Foundation IPR policies and 
> procedures<http://openid.net/foundation/intellectual-property/>this note 
> proposes the formation of a new working group chartered to produce
> an OpenID specification.  As per Section 4.1 of the Policies, the specifics
> of the proposed working group are:
> **
>  *Trust Exchange (TX) Extension WG Charter*
>
> In accordance with the OpenID Foundation IPR policies and procedures this
> note proposes the formation of a new working group chartered to produce an
> OpenID specification.  As per Section 4.1 of the Policies, the specifics of
> the proposed working group are:
>
>
> Proposal:
>
> (a)  Charter.
>
>  (i)  WG name:  Trust Exchange Extension (TX)
>
>  (ii)  Purpose:  The purpose of this WG is to produce a standard OpenID
> extension to the OpenID Authentication protocol that enables arbitrary
> parties to create and exchange a mutually-digitally-signed legally binding
> "contract". This protocol extension aims to be both broadband and mobile
> friendly by defining appropriate bindings for each use case.
>
> Although this specification defines one default protocol for transfering
> data based on the contract, the data transfer portion is intended to be
> pluggable so that other protocols may also be used for this purpose.
>
> The extension is not intended to be a general method for defining
> attributes; the scope is limited to a specific set of attributes necessary
> for contract semantics. The extension will also define a contract signature
> based on public key cryptography. When used with a digital certificate
> signed by a third party, the contract and signature can be used as an
> assertion of conformance to an applicable assurance program.
>
>  (iii)  Scope:
>
> Scope of the work
>
>-Development of the specification including:
>
>
> - An extensible tag-value contract format
>   - Public Key Cryptography based digital signature method applied to
>   the above contract format
>   - Query/response communication protocols for establishing the
>   contract
>   - Default data transfer protocol based on the contract
>   - Conformance requirements for other data transfer protocol bindings
>
>
>- Security, threats and Risk analysis
>
>
> - Perform Security Risk analysis and profiles for best practice
>
>  Out of scope
>
>- Term negotiation: Actual negotiation of the terms of a contract
>should be dealt with out-of-band or by other specifications.
> - General purpose data type identifiers: this should be determined on
>a per-community bases using other specifications such as OpenID Attribute
>Exchange.
> - Assurance programs or other identity governance frameworks.
> - It is the in

Proposal to create the TX working group

[Nat Sakimura]

Dear Specification Council members:

In accordance with the OpenID Foundation IPR policies and procedures
<http://openid.net/foundation/intellectual-property/> this note proposes
the formation of a new working group chartered to produce an OpenID
specification. As per Section 4.1 of the Policies, the specifics of the
proposed working group are:
**



  *Trust Exchange (TX) Extension WG Charter*

In accordance with the OpenID Foundation IPR policies and procedures
this note proposes the formation of a new working group chartered to
produce an OpenID specification. As per Section 4.1 of the Policies, the
specifics of the proposed working group are:


Proposal:

(a) Charter.

(i) WG name: Trust Exchange Extension (TX)

(ii) Purpose: The purpose of this WG is to produce a standard OpenID
extension to the OpenID Authentication protocol that enables arbitrary
parties to create and exchange a mutually-digitally-signed legally
binding "contract". This protocol extension aims to be both broadband
and mobile friendly by definingappropriatebindings for each use case.

Although this specification defines one default protocol for transfering
data based on the contract, the data transfer portion is intended to be
pluggable so that other protocols may also be used for this purpose.

The extension is not intended to be a general method for defining
attributes; the scope is limited to a specific set of attributes
necessary for contract semantics. The extension will also define a
contract signature based on public key cryptography. When used with a
digital certificate signed by a third party, the contract and signature
can be used as an assertion of conformance to an applicable assurance
program.

(iii) Scope:

Scope of the work

* Development of the specification including:

  o An extensible tag-value contract format
  o Public Key Cryptography based digital signature method
applied to the above contract format
  o Query/response communication protocols for establishing the
contract
  o Default data transfer protocol based on the contract
  o Conformance requirements for other data transfer protocol
bindings

* Security, threats and Risk analysis

  o Perform Security Risk analysis and profiles for best practice

Out of scope

* Term negotiation: Actual negotiation of the terms of a contract
  should be dealt with out-of-band or by other specifications.
* General purpose data type identifiers: this should be determined
  on a per-community bases using other specifications such as OpenID
  Attribute Exchange.
* Assurance programs or other identity governance frameworks.
* It is the intent that this specification be usable by any trust
  community, whether it uses conventional PKI hierarchies,
  peer-to-peer trust mechanisms, reputation systems, or other forms
  of trust assurance. The specification of any particular trust
  root, trust hierarchy, or trust policy is explicitly out of scope.


(iv) Proposed List of Specifications: TX 1.0, spec completion expected
in January 2009.

(v) Anticipated audience or users of the work: Implementers of OpenID
Providers and Relying Parties, especially those who require security and
accountability features to exchange sensitive customer information (e.g.
personally identifiable information and credit card numbers) responsibly
among trusted parties.

(vi) Language in which the WG will conduct business: English.

(vii) Method of work: E-mail discussions on the working group mailing
list, working group conference calls, and possibly face-to-face meetings
at conferences.

(viii) Basis for determining when the work of the WG is completed: Draft
1 will be evaluated on the basis of whether they increase or decrease
consensus within the working group. The work will be completed once it
is apparent that maximal consensus on the draft has been achieved,
consistent with the purpose and scope.

(b) Background Information.

(i) Related work being done by other WGs or organizations:

* LIberty Alliance Identity Governance Framework (IGF) 1.0 Draft
  
<http://www.projectliberty.org/liberty/content/download/4329/28939/file/liberty-igf-draft-1.0-2008-06-21.zip>

* XML Advanced Electronic Signatures (XAdES)
  <http://www.w3.org/TR/XAdES/>


(ii) Proposers:

Drummond Reed, [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>, Cordance/Parity/OASIS (U.S.A)
Henrik Biering, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>, Netamia (Denmark)
Hideki Nara, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>, Tact
Communications (Japan)
John Bradeley, [EMAIL PROTECTED], OASIS IDTrust Member Section (Canada)
Mike Graves, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>, JanRain,
Inc. (U.S.A.)
Nat Sakimura, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>, Nomura
Research Institute, Ltd.(Japan)
Robert Ott, [EMAIL PROTECTED

Re: "This is user's URI" for Assertion Quality Extension

[Nat]

Obvious use case would be that psudonimous user wanting to be  
recognized as the same person as the previous visit but not willing to  
give up his privacy. Thisbis a classic use case in both XRI and Liberty.

[EMAIL PROTECTED] via iPhone

On 2008/09/05, at 16:09, Martin Atkins <[EMAIL PROTECTED]> wrote:

> SitG Admin wrote:
>> http://openid.net/specs/openid-assertion-quality- 
>> extension-1_0-03.html
>> > >
>> I'd like to see the 4th draft of this include a "URI level"
>> authentication property.
>>
>> I'd like to know whether the OP is asserting that the user "is a  
>> member
>> of Site", "is this specific user *at* Site", or "is a member of  
>> Site and
>> we've generated this unique Directed Identity for them that won't  
>> reveal
>> their userID at Site but will allow you, the RP, to distinguish  
>> between
>> this anonymous Site user and other anonymous Site users".
>>
>
> What's the use-case?
>
> ___
> 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: "This is user's URI" for Assertion Quality Extension

[Nat]

Come in to PAPE WG! We are a bit lonely right now :-) IMHO, identity  
assurance is THE THING you need for the RP adoption, and it is  
important enough for many more people to get involved on the discussion.


[EMAIL PROTECTED] via iPhone

On 2008/09/05, at 11:19, SitG Admin <[EMAIL PROTECTED]>  
wrote:



http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html
I'd like to see the 4th draft of this include a "URI level"  
authentication property.


I'd like to know whether the OP is asserting that the user "is a  
member of Site", "is this specific user *at* Site", or "is a member  
of Site and we've generated this unique Directed Identity for them  
that won't reveal their userID at Site but will allow you, the RP,  
to distinguish between this anonymous Site user and other anonymous  
Site users".


-Shade
___
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: Backporting the 2.0 extension mechanism to 1.1

[Nat Sakimura]

Since PAPE needs more integrity in the message (otherwise, the whole 
point of PAPE is lost), it would be ok to leave it just to OpenID 2.0 
and make it an incentive to move to OpenID 2.0, IMHO.

=nat

Johnny Bufu wrote:
> On 11/08/08 10:35 AM, Martin Atkins wrote:
>   
>> In that referenced section it says:
>>
>>  For the purposes of this document *and when constructing OpenID 1.1
>>  messages*, the extension namespace alias SHALL be "pape".
>>
>> (emphasis mine)
>>
>> I understand that to mean that when making a 1.1 request the alias must 
>> be "pape".
>> 
>
> You're right - my brain must have left out the portion you emphasized,
> since it didn't use to be there.
>
> I thought PAPE was not meant to be compatible with 1.1, exactly for the
> reasons you outlined in the initial message.
>
> Not sure what the best approach would be here: specify how PAPE could be
> used with OpenID 1.1, or leave it as an incentive to upgrade to 2.0.
>
> Johnny
>
>
>
>
> ___
> 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: Backporting the 2.0 extension mechanism to 1.1

[Nat Sakimura]

Actially, that interpretation is not right. In draft 3, we have made  
it clear.

[EMAIL PROTECTED]

On 2008/08/12, at 2:35, Martin Atkins <[EMAIL PROTECTED]> wrote:

> Johnny Bufu wrote:
>>
>>
>> On 11/08/08 12:49 AM, Martin Atkins wrote:
>>> I notice that, like sreg, the pape extension is supporting 1.1 by
>>> simply hard-coding the "pape" prefix on its arguments.
>>
>> Where/how? To my knowledge the opposite is true, per the last  
>> paragraph
>> here:
>>
>> >  
>> >
>>
>
> In that referenced section it says:
>
> For the purposes of this document *and when constructing OpenID  
> 1.1
> messages*, the extension namespace alias SHALL be "pape".
>
> (emphasis mine)
>
> I understand that to mean that when making a 1.1 request the alias  
> must
> be "pape".
>
> ___
> 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: Non-interactive logins

[Nat Sakimura]

The implementation we have done at JAL is composed of the following:

1) Normal OpenID Auth 2.0 procedure
2) Extention to hook contract negotiation upon OpenID Auth 2.0 procedure
3) Actual Contract and back channel data transfer protocol negotiation.
4) Actual data transfer.

For 2) and 3) above, the service provider issues a signed contract 
proposal,
and the end user is shown the terms and conditions. If end user agrees 
to it or
part of it, the term is finalized and counter signed, and its URL is 
sent back
with OpenID authentication response. This contract gives non-repudiation
to the parties.

There after, the service provider can use the contract to retrive the 
desired data
as par specified in the contract.

The data transfer protocol can be anything. It can be OAuth, ID-WSF or
something else, which should be specified in the contract. (Does not 
have to be:
if the data acqusition URL can expose XRDS and publicise the available
data transfer protocols, it can be done dynamically.)

It was first reviewd at iiw2007b and the basic flow has been on the 
OpenID wiki for sometime:
http://wiki.openid.net/Trusted_Data_Exchange , though it is a bit out of 
date.

Also, the name Trusted Data Exchange, but the name is not quite
depictive, so, it probably should be decomposed into "Contract 
Negotiation",
and something else.

Note that this system has been live since the end of May this year, in 
the real transaction of monetary value.

I do plan to propose it as the WG in the coming weeks. If you would like 
to join in the boat, you are more than welcome :-)

=nat


Anders Feder wrote:
> tir, 15 07 2008 kl. 21:28 -0700, skrev John Panzer:
>   
>> And of course any number of extensions could be created to obtain an
>> access token via an alternate path, after which normal OAuth can be
>> used.
>> 
>
> Sure, but isn't this equally true for OpenID?
>
> If that is the case, I would like to ask the list if anybody is
> interested in working towards such an extension.
>
>   
>>> Joseph Holsten pointed me to Appendix A of the OAuth specification for
>>> an example. In step A.3, "The Consumer redirects Jane’s browser to the
>>> Service Provider User Authorization URL to obtain Jane’s approval for
>>> accessing her private photos."
>>>
>>> Also, OAuth appears to be more about authorization (to access a remote
>>> resource) than about authentication.
>>>
>>> Is there any way to operate either OpenID or OAuth entirely
>>> non-interactively?
>>>
>>> tir, 15 07 2008 kl. 08:38 -0700, skrev Scott Kveton:
>>>
>>>   
>>>> Hi Anders,
>>>>
>>>> You might want to check out OAuth ... it was developed for just such a
>>>> situation.
>>>>
>>>> - Scott
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jul 15, 2008 at 4:20 AM, Anders Feder <[EMAIL PROTECTED]> wrote:
>>>>
>>>> 
>>>>> Hello,
>>>>>
>>>>> There have been some discussion over the years about using OpenID for
>>>>> non-interactive logins. Can someone kindly tell me what the status is of
>>>>> this feature? In particular login from non-browser applications - is
>>>>> this currently possible (e.g. using client certificate authentication)?
>>>>> Thanks.
>>>>>
>>>>> --
>>>>> Anders Feder <[EMAIL PROTECTED]>
>>>>>
>>>>> ___
>>>>> specs mailing list
>>>>> specs@openid.net
>>>>> http://openid.net/mailman/listinfo/specs
>>>>>
>>>>>
>>>>>   
>>> ___
>>> specs mailing list
>>> specs@openid.net
>>> http://openid.net/mailman/listinfo/specs
>>>
>>>   
> --
> Anders Feder <[EMAIL PROTECTED]>
>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>   

-- 
Nat Sakimura (=nat)
Nomura Research Institute, Ltd. 
XDI.ORG Vice Chair

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

Re: [OpenID board] The Specifications Council

[Nat Sakimura]

Great!


On Wed, Jun 4, 2008 at 3:23 AM, Dick Hardt <[EMAIL PROTECTED]> wrote:
> Fabulous!
>
> On 3-Jun-08, at 11:20 AM, David Recordon wrote:
>
>> The past editors of OpenID Authentication 2.0 (Josh Hoyt, Johnny Bufu,
>> and myself) just got off a phone call where we elected the remaining
>> five individuals to the specification council.  As everyone knows, the
>> council is designed to both create a separation between the board of
>> the OIDF and the community technical working groups and to provide
>> guidance as future OpenID specifications are being developed.  We've
>> thus unanimously elected the following individuals to the council to
>> serve the initial term joined by Dick Hardt and Mike Jones from the
>> OIDF board:
>>
>>  - Allen Tom
>>  - Brad Fitzpatrick
>>  - David Recordon
>>  - Johnny Bufu
>>  - Josh Hoyt
>>
>> ___
>> board mailing list
>> [EMAIL PROTECTED]
>> http://openid.net/mailman/listinfo/board
>>
>>
>
> ___
> board mailing list
> [EMAIL PROTECTED]
> http://openid.net/mailman/listinfo/board
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: Proposal to create the PAPE working group

[Nat Sakimura]

Perhaps you could explain to the list what the process will be after
this, such as:

1) Specification Council to approved PAPA WG.
2) Call for Participation ... etc.

IMHO, that will help the community to understand the process a lot.

By the way, I plan to respond to 2) above. I could have been a
proposer of the WG, but to debug the process, somebody has to do the
role of responder to the call for participation, so...  :-)

=nat

2008/5/23 Mike Jones <[EMAIL PROTECTED]>:
> This message is being sent to revise the proposal to create the PAPE working
> group, changing only one word, so that the projected completion date is July
> 2008, rather than May 2008.  The complete text of the revised proposal
> follows.
>
>
>
> --- Mike
>
>
>
> In accordance with the OpenID Foundation IPR policies and procedures this
> note proposes the formation of a new working group chartered to produce an
> OpenID specification.  As per Section 4.1 of the Policies, the specifics of
> the proposed working group are:
>
>
>
> Proposal:
>
> (a)  Charter.
>
> (i)  WG name:  Provider Authentication Policy Extension
> (PAPE)
>
> (ii)  Purpose:  Produce a standard OpenID extension to the
> OpenID Authentication protocol that:  provides a mechanism by which a
> Relying Party can request that particular authentication policies be applied
> by the OpenID Provider when authenticating an End User and provides a
> mechanism by which an OpenID Provider may inform a Relying Party which
> authentication policies were used. Thus a Relying Party can request that the
> End User authenticate, for example, using a phishing-resistant and/or
> multi-factor authentication method.
>
> (iii)  Scope:  Produce a revision of the PAPE 1.0 Draft 2
> specification that clarifies its intent, while maintaining compatibility for
> existing Draft 2 implementations.  Adding any support for communicating
> requests for or the use of specific authentication methods (as opposed to
> authentication policies) is explicitly out of scope.
>
> (iv)  Proposed List of Specifications:  Provider
> Authentication Policy Extension 1.0, spec completion expected during July
> 2008.
>
> (v)  Anticipated audience or users of the work:
> Implementers of OpenID Providers and Relying Parties – especially those
> interested in mitigating the phishing vulnerabilities of logging into OpenID
> providers with passwords.
>
> (vi)  Language in which the WG will conduct business:
> English.
>
> (vii)  Method of work:  E-mail discussions on the working
> group mailing list, working group conference calls, and possibly a
> face-to-face meeting at the Internet Identity Workshop.
>
> (viii)  Basis for determining when the work of the WG is
> completed:  Proposed changes to draft 2 will be evaluated on the basis of
> whether they increase or decrease consensus within the working group.  The
> work will be completed once it is apparent that maximal consensus on the
> draft has been achieved, consistent with the purpose and scope.
>
> (b)  Background Information.
>
> (i)  Related work being done in other WGs or organizations:
> (1) Assurance Levels as defined by the National Institute of Standards and
> Technology (NIST) in Special Publication 800-63 (Burr, W., Dodson, D., and
> W. Polk, Ed., "Electronic Authentication Guideline," April 2006.)
> [NIST_SP800‑63].  This working group is needed to enable authentication
> policy statements to be exchanged by OpenID endpoints.  No coordination is
> needed with NIST, as the PAPE specification uses elements of the NIST
> specification in the intended fashion.
>
> (ii)  Proposers:
>
> Michael B. Jones, [EMAIL PROTECTED],
> Microsoft Corporation
>
> David Recordon, [EMAIL PROTECTED], Six
> Apart Corporation
>
> Ben Laurie, [EMAIL PROTECTED], Google
> Corporation
>
> Drummond Reed, [EMAIL PROTECTED],
> Cordance Corporation
>
> John Bradley, [EMAIL PROTECTED],
> Wingaa Corporation
>
> Johnny Bufu, [EMAIL PROTECTED],
> Independent
>
> Dick Hardt, [EMAIL PROTECTED],  Sxip Identity
> Corporation
>
> Editors:
>
> Michael B. Jones, [EMAIL PROTECTED],
> Microsoft Corporation
>
> David Recordon, [EMAIL PROTECTED], Six
> Apart Corporation
>
&

Re: Login Federation

[Nat Sakimura]

Actually, there seems to be.

I was reading through the documents today and found about it.

http://openid.net/ipr/OpenID_Process_Document_(Final_Clean_20071221).pdf

Basically,

1. Contributors for the new spec Sign the Contribution Agreement and
gather more than five proposed WG members.
2. Apply for a new Work Group to specs@openid.net
=> This needs to fulfil certain requirement.
3. Get the approval from the Specification Council which is composed of
two board members and five current and ex-editors (“Eligible Editors").
> Who are the members of the current Specification Council?
4. Start WG. Spec needs to go through three stages process:
Draft -> Implementors Draft -> Final
Basically, WG needs concensus to propose the spec to be implementors 
draft etc.
to the members.After certain review period, members get to vote.
The quorum is greater of 20% of OIDF members or 20 OIDF members.

Regards,

=nat

Brett Carter wrote:
> John Ehn wrote:
>   
>> Sounds good.  I'm working on a draft.  Once it's in a readable state,
>> I'll post it for comments.
>>
>> Thanks!
>> 
>
> Is there a formal process for submitting a proposal yet?  Or are we just
> going with RFC format for now?
> -Brett
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>   

-- 
Nat Sakimura (=nat)
Nomura Research Institute, Ltd. 

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

Re: Login Federation

[Nat Sakimura]

In a single domain scenario, such as inside a corporation, one could 
issue a domain cookies having op_identifier or claimed_id and RP can 
start the authentication request based on this. It is not in the spec, 
but can easily be done.

In a multi domain scenario such as the Internet, it is not that simple. 
If the sites are in a same "Circle of trust", then they can set up a 
shared server with multiple domain names and issue identical domain 
cookie a la Liberty. This is essential the same as the single domain 
scenario, then. This again is not in the spec.

If this is not desired or possible, things does not work out so nicely 
then.
You need a way to tell RP the OP somehow. One possible way is always to 
jump from a link page but that is not very realistic. Using a browser 
plug-in is another. Of course, this is not a spec either...

Regards,

Nat

Brett Carter wrote:
> I've dug around a bit, and haven't found anything, so I thought I'd
> ask here.  Is any work being done on adding some sort of federated
> login for open id?  By 'federated' I simply mean that signing into my
> open id provider, this automatically signs me into all my open id
> enabled sites (of my choice) at once.
>
> I have a few ideas I'd like to kick around if somebody isn't already
> working on this.  If so, please feel free to point me in the right
> direction.
> -Brett
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>   

-- 
Nat Sakimura (=nat)
Nomura Research Institute, Ltd. 

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

Re: OpenID 3.0

[Nat Sakimura]

Hi.

For

> 4. A way to indicate to the relying party what level of
> authentication has occurred such as did the OP 
> check a password, how did it validate a user. 
> Without this, there is no way that a trust 
> model could be established in a credible way. 

like it was mentioned before PAPE does some job, and AQE does some other. 
Of course, that is only the claim that OP makes, so there has to be some kind 
of trust framework, where I belive that reputation comes in. 

> 5. A way for OpenID relying parties to filter out Ops. In a business
> scenario, if I run the Sun employee store, I may only want the Sun
> OP to talk with me. 

Simple way of doing this is white list. Many does this already. 
More dynamic one would use Reputation Service. 

Reputation Service would be another (sort of ) extention, IMHO. 

On the reputation, I wrote a bit on my blog, so you may want to read it as 
well. 

http://www.sakimura.org/en/modules/wordpress/index.php?p=30

Re: OpenID 3.0

While we were writing (are still writing) OpenID Trusted data Exchange 
(TX) proposal, we started to feel that if we introduce Reputation 
Service appropreately, we can skip the association and 
check_authentication entirely. If this kind of change would make the 
protocol faster and more secure, we perhaps can start considering it in 
the core spec., but otherwise, they should be done as extension spec. 
Rule of the thumb perhaps is that unless we need to touch / change the 
basic flow of the core protocol, we do not need to go to 3.0.

Regards,

=nat

Johannes Ernst wrote:
> Amen. Let's build (optional) extensions, and only if that absolutely
> does not work for an essential feature, meekly suggest that the
> smallest possible set of changes be made to an existing spec.
>
> Note that any term such as "OpenID 3.0" is mostly a marketing /
> branding term, just like "OpenID 2.0". What it really means is what
> underlying specs are being "packaged" into a larger term.
>
> On Feb 2, 2008, at 2:36, Martin Atkins wrote:
>
>   
>> I apologise that this message doesn't directly address any of the
>> points
>> you've made, but others have been doing that.
>>
>> I just want to make a general point:
>> In my opinion, we should resist the urge to start specing "OpenID 3.0"
>> (aka OpenID vNext) and try to do everything else that needs to be done
>> with extensions now. OpenID 2.0 has laid the framework for
>> decentralized
>> extensibility, so it should now be much easier to work within that
>> framework.
>>
>> If it turns out that some particular feature absolutely can't be done
>> without making a new Authentication spec release then so be it, but
>> ideally I think we want 2.0 to be stable for many years to come to
>> avoid
>> repeating all of the current pain of incompatible versions and the
>> poor
>> user experience that creates.
>>
>>
>> McGovern, James F (HTSC, IT) wrote:
>> 
>>> Figured I would ask if anyone is interested in brainstorming the next
>>> version of OpenID and how it can be used in Enterprise B2B settings
>>> and
>>> not solely focusing on consumerish interactions. Some things that I
>>> would like to see in the next version are:
>>>
>>> 1. A discussion on how AuthZ can converge with OpenID
>>> 2. Modeling of relationships
>>> 3. Not allowing an OpenID to be a vector for SQL Injection and
>>> putting
>>> something around what it should look like
>>> 4. A way to indicate to the relying party what level of
>>> authentication
>>> has occurred such as did the OP check a password, how did it
>>> validate a
>>> user. Without this, there is no way that a trust model could be
>>> established in a credible way.
>>>
>>> 5. A way for OpenID relying parties to filter out Ops. In a business
>>> scenario, if I run the Sun employee store, I may only want the Sun
>>> OP to
>>> talk with me.
>>>
>>>   
>> ___
>> specs mailing list
>> specs@openid.net
>> 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: XACML

[Nat Sakimura]

Hi James,

I am definitely interested in something like that.
It has been a long standing ToDo for me, though
currently, my focus is more on the reputation side
because I need it now for an implementation that we are
doing now (for enterprise use.)

Nat

Bill Washburn wrote:

> Hi James--
> 
> Thanks for your note.  The OpenID community, made up of a considerable 
> and growing number of developers, website operators, enterprises large 
> and small, and of course end-users, cannot be spoken for by me alone or 
> by the OpenID Foundation Board in any seriously comprehensive way.  Of 
> course there are members of the community who have already developed and 
> are working assiduously now to provide added functionality supporting 
> and serving enterprise specific requirements.
> 
> Having said that, I'm fully focused these days on membership and 
> organizational efforts for OpenID Foundation and I'm not the right 
> person to recommend names of individuals engaged in specific efforts to 
> support XACML, relationship modeling, and so forth.  I'm certain 
> individuals on the specs list will be able to address your substantive 
> information request.
> 
>  From the Foundation's perspective, however, I would certainly 
> appreciate the chance to talk with you about The Hartford company taking 
> the step of becoming a pioneering member of the OpenID community from 
> the insurance world.  I hope we'll have the opportunity to talk soon.
> 
> Thanks again for your inquiry.
> 
> cheers,
> -bill
> 
> Bill Washburn
> Executive Director
> OpenID Foundation
> +1 707 545 4823 (office)
> +1 650 248 6113 (cell)
> 
> 
> On Dec 11, 2007 9:31 AM, McGovern, James F (HTSC, IT) < 
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 
> wrote:
> 
>  OpenID 2.0 seems to have closed major security gaps and is usable in a
> consumer context. Are their plans to figure out how to add functionality
> to the next version of OpenID to support more enterprise considerations
> including support for XACML, modeling of relationships, attestation, etc
> or is the focus of participants here strictly consumer oriented?
> 
> 
> *
> 
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or
> distribution is
> strictly prohibited.  If you are not the intended recipient, please
> notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *
> 
> 
> ___
> specs mailing list
> specs@openid.net <mailto:specs@openid.net>
> http://openid.net/mailman/listinfo/specs
> <http://openid.net/mailman/listinfo/specs>
> 
> 



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

Re: OpenID support for XACML

[Nat Sakimura]

It would be interesting to me, at least.
My team is currently considering using OpenID for real business 
transactions and sorting out what is there and what is not there. For 
something that is not there, we have to create one and perhaps propose 
as a spec.

Nat

McGovern, James F (HTSC, IT) wrote:
>  Currently OpenID 2.0 is targeted for supporting consumer-oriented
> interactions. I would love to develop a sense as to when/if members of
> OpenID have any interest in sketching out B2B interactions where not
> only identity is important but also assertion of authorization
> information at runtime via XACML will be discussed?
>
> Players such as Vidoop can further expand their value proposition if
> they were to noodle XACML support as part of OpenID as there are tons of
> industry vertical federations that would benefit from such a solution...
>
>
> *
> This communication, including attachments, is
> for the exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information.  If you are not the intended
> recipient, any use, copying, disclosure, dissemination or distribution is
> strictly prohibited.  If you are not the intended recipient, please notify
> the sender immediately by return e-mail, delete this communication and
> destroy all copies.
> *
>
> ___
> 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: [Idschemas] identity schema element metadata: using existingspecifications

[Nat Sakimura]

Hi,

Instead of having one single master copy at the IdP, I would prefer one 
single piece of each information disparsed over the network (optionally 
with opaque identifiers) and having IdP managing the "links" so that I 
can control all the pieces from one place. I feel that having everything 
at one place is too risky.

=nat

Chris Drake wrote:
> Hi,
>
> Having missed the summit - can anyone tell if there was any dissent or
> scaremongering going on?  The idea of assisting everyone who's
> collecting information about me, to share it easily, seems like an
> exceptionally "Bad Idea" (tm).
>
> If anyone's building anything that assists these companies to "give
> up" or relinquish their collection of my data, in favor of letting me
> hold the one single master copy if it myself, on my chosen IdP, and to
> let me arbitrate who can use it, when, and how - now *that* would be
> something to congratulate people about.
>
> Search google/google-news for "paper shredder" ...
>
> Kind Regards,
> Chris Drake,
> =1id.com
>
>
> Saturday, September 8, 2007, 5:33:20 PM, you wrote:
>
> DR> Mark,
>
> DR> I just wanted to say that based on what I learned about them at the Data
> DR> Sharing Summit (http://datasharingsummit.com) today, and what I read on my
> DR> first pass tonight, these are fine pieces of work that really push the 
> ball
> DR> forward.
>
> DR> Hats off to you.
>
> DR> =Drummond
>
>   
>>> -Original Message-
>>> From: [EMAIL PROTECTED] [mailto:idschemas-
>>> [EMAIL PROTECTED] On Behalf Of Mark Wahl
>>> Sent: Thursday, September 06, 2007 6:05 PM
>>> To: ID Schemas
>>> Cc: OpenID specs list
>>> Subject: [Idschemas] identity schema element metadata: using
>>> existingspecifications
>>>
>>>
>>> I'm reformatting the table of identity schema metadata, located at
>>> http://idschemas.idcommons.net/moin.cgi/MetaData, into a
>>> pair of more compact and usable specifications. One spec describes
>>> where the existing well-known metadata (e.g., Dublin Core) should be
>>> used when describing identity schemas and their schema elements (i.e.,
>>> attribute types and claim types).  The other spec will describe how
>>> to represent identity schema metadata for which there is no
>>> pre-existing well-known specification.  I've attached a copy of
>>> the first draft of the "Identity Schema Element Metadata: Using
>>> Existing Specifications".
>>>
>>> Mark Wahl
>>> Informed Control 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: Specifying identifier recycling

[=nat]

Hi. 

Ok. Now I see the heart of the topic :-)

Fundamental difference is that you postulate that one cannot lose one's 
credential including all the information that bears onto establish one's 
identity while I do not postulate so. 

For example, one can loose one's password and reset it. 
You can loose your credit card and replace it. 
Doing so has not nullished your "identity". You still are yourself. 
Your identity itself and the attribute associated with it apart from this 
particular lost credential data (whether it was a password or credit card) 
stays intact. 

This picture changes dramatically when you use public key 
as your main identity address. If you lose your private key, 
that's the end of story. Your relationships with all the RPs are ruined. 

That is why I believe that we should not be using this kind of public key 
as the identification data for RPs. 

Also, mandating OPs to specify a unique opaque string as the 
identification data would be much simpler than requiring parties to 
do public key verification, I think :-)

Having said that, I do agree that we should be completing 2.0 cycle 
quickly and making it SIMPLE!

Nat


> -Original Message-
> From: Johannes Ernst [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, June 05, 2007 1:45 PM
> To: =nat
> Cc: 'OpenID specs list'
> Subject: Re: Specifying identifier recycling
> 
> I would postulate that if you want to be able to prove your 
> identity, you cannot allow your credential to be lost, 
> interpreting "credential" to be all the information that 
> bears onto establishing your identity. (saying it this way, 
> it is a tautology.)
> 
> This is independent of whether anybody uses public keys, or 
> any other technology. So I very strongly suspect that while 
> it may be more apparent to you guys that the issue exists for 
> public key technology, it also exists for all other 
> approaches, whether we know them at this time or not!
> 
> However, I can readily see that strong voices (that'd be you 
> guys ;-)) are not ready to adopt any kind of public key 
> technology into the OpenID family, never mind whether X or Y 
> wins this particular argument. So we don't need to continue 
> this thread.
> 
> I continue to believe, however, as I have said before, that 
> we don't have enough of an agreement on the solution to be 
> able to standardize any of them at this time. (Personally, I 
> don't think we have agreement on the problems to be solved 
> either.) I'd much rather see our creative juices flowing on 
> the much larger problem of simplifying the OpenID Auth draft 
> in a manner that people say "this is much easier than 1.1" 
> instead of the opposite.
> 
> 
> On Jun 3, 2007, at 23:11, =nat wrote:
> 
> > Dick's concern is very valid, I think.
> >
> > I do not even want to think of the consequence of losing my 
> own main 
> > identity secret :-p
> >
> > =nat
> >
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt
> >> Sent: Sunday, June 03, 2007 8:24 PM
> >> To: Johannes Ernst
> >> Cc: OpenID specs list
> >> Subject: Re: Specifying identifier recycling
> >>
> >> There is a huge difference between the OP/RP shared secret 
> and using 
> >> a shared secret as an identifier.
> >>
> >> The secret between the OP and RP has a mechanism for it to be 
> >> recycled. If it happens to be lost, then the pair can set up a new 
> >> secret.
> >>
> >> If the user's secret is lost, then that identifier and any 
> accounts 
> >> that it was used for are lost.
> >>
> >> -- Dick
> >>
> >
> > ___
> > specs mailing list
> > specs@openid.net
> > http://openid.net/mailman/listinfo/specs
> 

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

Attribute Exchange external reference?

[=nat]

Hi. 

I am kind of new to this field, and this topic may have been discussed
before, but since a Google search on [site:http://openid.net/pipermail/
attribute exchange external reference ] did not match anything, let me bring
this up. 

On scanning http://openid.net/specs/openid-attribute-exchange-1_0-05.html,
which looked pretty good, a question "Would it be even nicer if we could
have a hook for external data source?" came up to my mind. 

For example, if we could write something like 

openid.ax.type.externalref=http://example.com/schema/industry_specific_data
openid.ax.value.externalref=http://example.com/specific_data.xml

in the response, and have the client fetch the document from http://example.
com/specific_data.xml (if it understands the schema type of it), it would be
useful in bringing OpenID framework and something else together. 

I initially thought that it could be done in the New Attribute Process
[http://openid.net/specs/openid-attribute-types-1_0-02.html#anchor6], but
since it requires fetching of external document and thus changes the client
behavior, I brought up this here. 

Any thought? 

=nat




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

RE: Specifying identifier recycling

[=nat]

Hi. 

My comments in-line below: 

On Saturday, June 02, 2007 5:40 AM, Johannes Ernst wrote: 
> 
> On May 31, 2007, at 18:41, Nat Sakimura wrote:
> 
> > Public key idea is somewhat attractive to me, but there are some 
> > issues that comes up in my mind as well.
> 
> Bring them on ;-)
> 
> > 1) Storing many users' private key on the server in 
> decryptable format 
> > is not very safe.
> >
> > In your proposal, it looks like that OP is going to hold 
> the private 
> > key for each user in decryptable format. Considering that 
> most large 
> > scale privacy leakage happens at the server side, I have 
> got a feeling 
> > that such thing like private key in a shared location.
> 
> How would this be less safe than storing many shared secrets 
> (per OpenID Auth) in decryptable format, or clear-text (more 
> likely) on the server?

Well, we should not store any :-) We would not need them, do we? 
Just hashes would do. 

> Note that these private keys would not be general-purpose 
> private keys, but only for the specific purpose we are 
> discussing here.

Actually, by Dick's comment, I am now realizing what was making me 
uneasy. I feel (sort of) ok on storing one's special purpose secret key on
the 
server just like server-side wallet, but I want it to be replaceable without
impacting 
my identity. i.e., it is ok to use the key to sign a message, but not make
the 
pub-key my identifier. (Having said that, I am still not clear why we should
need 
this for just AuthN. OP sigining the response on authenticating the user
does 
not seem much different. Also, keeping one key in HSM and securely operating

is easier than having millions of keys...)

> 
> Also, I suspect that the use of these keys would be fairly 
> infrequent compared to other operations, so conceivably one 
> could add additional safeguards of various kinds if that was needed.
> 
> > 2) It may mean a high cost operation for OPs.
> >
> > If we do this, it makes OP operation very high cost because to make 
> > the service safe, it would require a lot of measures. (NRI is 
> > providing similar kind of service but it indeed is very high cost 
> > operation.)
> >
> > Nice thing about i-number is that it has no value like public key 
> > except for its resolvability. Even if it leaks, that's kind 
> of ok so 
> > operational risk is low.
> 
> This comparison does not work very well for me. However: I 
> don't know the details of how to avoid "impersonation" via 
> i-numbers (in case of key pairs, it would be "private key 
> leaks and is reused by attacker"  
> -- what would be the equivalent for i-numbers?), but I 
> suspect there are some measures that prevent attackers from 
> impersonation by using somebody else's i-number? If so, 
> aren't they similarly susceptible to attack?

In the scenario that OP signs a unique string (whether it is i-number or
something else), 
impersonization happens when OP's key is stolen. However, as Dick points
out, 
we have a way to re-setup the keys between OP and RP. In case of "user
private key 
as a part of identity" leaks, we do not have a very good way of replacing
it. (Well, 
we cannot, as if we could, this will contradict its purpose as counter id
recycling measure. 
Note, if it is not part of identity string and just used to sign something
with public key 
discovery protocol, that is ok.) ( I also would like to point out that OP's
key leaking is 
much easier to monitor and detect than user's. )

> 
> > Actually, these private key pain may be eased by IBE (Identity Based
> > Encryption) but I need some more time to contemplate on it.
> 
> I had somebody else mention this to me -- I wonder whether 
> anybody could put together an actual proposal.

After some thinking, I started to think that this might not be a good idea
after all. 

> 
> > 3) Since OPs has an access to the users' private key, they 
> > may recycle them as well.
> >
> > IMHO, recycling is operational problem as well as a technical one.
> > i-number from a certified i-broker is somewhat trustable on the 
> > account of no recycling because of this operational 
> > restriction. Could 
> > there be operational restriction similart to that for 
> > general OPs as well?
> 
> There could, and -- I suspect -- in the longer term there 
> probably will, but the whole point about a decentralized 
> system like OpenID is to keep the playing field level without 
> a central entity in the middle for the maximum length of time 
> and scope possible.

Well, I am not talking about a central authority kind of thing. 
Having a uniquely identifying filed (whether canonicalI

RE: Specifying identifier recycling

[=nat]

Dick's concern is very valid, I think. 

I do not even want to think of the consequence of losing my own 
main identity secret :-p

=nat

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt
> Sent: Sunday, June 03, 2007 8:24 PM
> To: Johannes Ernst
> Cc: OpenID specs list
> Subject: Re: Specifying identifier recycling
> 
> There is a huge difference between the OP/RP shared secret 
> and using a shared secret as an identifier.
> 
> The secret between the OP and RP has a mechanism for it to be 
> recycled. If it happens to be lost, then the pair can set up 
> a new secret.
> 
> If the user's secret is lost, then that identifier and any 
> accounts that it was used for are lost.
> 
> -- Dick
> 

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

RE: Specifying identifier recycling

[Nat Sakimura]

Public key idea is somewhat attractive to me, but there are some issues that
comes up in my mind as well. 

1) Storing many users' private key on the server in decryptable format is
not very safe. 

In your proposal, it looks like that OP is going to hold the private key for
each user in decryptable format. Considering that most large scale privacy
leakage happens at the server side, I have got a feeling that such thing
like private key in a shared location.

2) It may mean a high cost operation for OPs. 

If we do this, it makes OP operation very high cost because to make the
service safe, it would require a lot of measures. (NRI is providing similar
kind of service but it indeed is very high cost operation.) 

Nice thing about i-number is that it has no value like public key except for
its resolvability. Even if it leaks, that's kind of ok so operational risk
is low. 

Actually, these private key pain may be eased by IBE (Identity Based
Encryption) but I need some more time to contemplate on it. 

3) Since OPs has an access to the users' private key, they may recycle them
as well. 

IMHO, recycling is operational problem as well as a technical one. 
i-number from a certified i-broker is somewhat trustable on the account of
no recycling because of this operational restriction. Could there be
operational restriction similart to that for general OPs as well? 

=nat





> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Ernst
> Sent: Thursday, May 31, 2007 2:30 PM
> To: OpenID specs list
> Subject: Re: Specifying identifier recycling
> 
> If we cannot assume that nobody manages to obtain a secret they  
> should not have gotten in the first place, then OpenID as it stands  
> is rather useless as we cannot trust its  authentication scheme.
> 
> Note that the surface through which the D-H shared secret can escape  
> is about twice as large as the surface through which a private key  
> can escape -- because an RP does not have access to the private key.  
> In other words, if I was an attacker, I'd go after a lot of things  
> first before I'd try to obtain a private key.
> 
> Note also that public keys would make rather good i-numbers -- for  
> those who would like to, they can ignore that they are public keys  
> and do i-number-based verification only, because they are simply  
> numbers. For those who don't care about i-numbers, they use their  
> public key aspects. Win-win, perhaps?
> 
> There is also the case -- which Stefan Brands would 
> undoubtedly bring  
> up if he was on this list -- that the IdP may be hostile, or may  
> become hostile. (think of, say, a large OpenID provider going out of  
> business, and being bought out by spammer.com -- or just the domain  
> name whose registration lapsed) A scheme that is public key based is  
> inherently more resilient towards this than one that is not. You  
> certainly don't want to trust spammer.com to honor whatever  
> conventions the previous owner of the domain put in place to  
> disambiguate their users.
> 
> --
> 
> Overall, I'm not sure we are ready in this community to pick one  
> alternative over another as "the standards". I have my views, (many)  
> others have (many) others -- and I don't think that any of this has  
> to be in an Authentication 1.x (x>1) or 2.0 spec, whatever it will  
> be. This seems like a clean add-on.
> 
> 
> 
> On May 30, 2007, at 22:01, Drummond Reed wrote:
> 
> > Johannes:
> >
> > What about the point Dick posted earlier in this thread, that the  
> > problem
> > with using a public key is if the private key gets compromised?  
> > Persistent
> > identifiers need to persist independent of any attribute changing  
> > or being
> > revoked.
> >
> > =Drummond
> >
> > -Original Message-
> > From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On  
> > Behalf
> > Of Johannes Ernst
> > Sent: Wednesday, May 30, 2007 9:54 PM
> > To: OpenID specs list
> > Subject: Re: Specifying identifier recycling
> >
> >
> > On May 30, 2007, at 21:02, Johnny Bufu wrote:
> >
> >> ...The bottom line is
> >> that it can't be done easily - a mechanism similar to 
> XRI's canonical
> >> ID verification would have to be employed, to confirm that the i-
> >> number actually 'belongs' to the URL on which discovery was
> >> initiated. (Otherwise anyone could put any i-number in their URL-
> >> based XRDS files.)
> >
> > Public keys ... public keys ... with the added benefit that no
> > centralized or trusted verification service needs to be employe