Re: [OpenID] Signing method for XRD

2009-06-12 Thread Nat Sakimura
  -- 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 list
  specs@openid.net mailto:specs@openid.net
  http://openid.net/mailman/listinfo/specs
 
 
  ___
  specs mailing list
  specs@openid.net mailto:specs@openid.net
  http://openid.net/mailman/listinfo/specs
 
 
 ___
 specs mailing list
 specs@openid.net mailto:specs@openid.net
 http://openid.net/mailman/listinfo/specs




 --
 David Garcia
 CTO

 Tractis - Online contracts you can enforce
 http://www.tractis.com
 --
 Tel: (34) 93 551 96 60 (ext. 260)

 Email: david.gar...@tractis.com mailto:david.gar...@tractis.com
 Blog: http://blog.negonation.com
 Twitter: http://twitter.com/tractis
 --
 David Garcia
 CTO
 Tractis - Online contracts you can enforce
 http://www.tractis.com
 --
 Tel: (34) 93 551 96 60 (ext. 260)
 Email: david.gar...@tractis.com mailto:david.gar...@tractis.com
 Blog: http://blog.negonation.com
 Twitter: http://twitter.com/tractis
 
 ___
 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] Signing method for XRD

2009-06-11 Thread 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

XRD sig=signature sigalg=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 jernst+openid.net@
netmesh.us 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


Re: [OpenID] Signing method for XRD

2009-06-11 Thread 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 a...@yahoo-inc.com 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 santra...@gmail.comwrote:


 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


OAuth Hybrid and UI ML?

2009-06-11 Thread 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: Requiring Pseudonymous Identifier

2009-05-13 Thread 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 dick.ha...@gmail.com 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


Re: Requiring Pseudonymous Identifier

2009-05-13 Thread Nat Sakimura
On Thu, May 14, 2009 at 12:46 AM, SitG Admin
sysad...@shadowsinthegarden.com 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

2009-05-13 Thread 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 gffle...@aol.com 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 gffle...@aol.com
 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,

        =nat

        On Tue, May 12, 2009 at 5:55 PM, Dick Hardt
        dick.ha...@gmail.com mailto:dick.ha...@gmail.com 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

Re: Identifier for group of individulas

2009-05-13 Thread 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 andrewarn...@gmail.com 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 santra...@gmail.com 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 sakim...@gmail.com
  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: Identifier for group of individulas

2009-05-13 Thread 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 andrewarn...@gmail.com 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 sakim...@gmail.com 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 andrewarn...@gmail.com
 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 santra...@gmail.com
  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 sakim...@gmail.com
   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

Re: OpenID Security

2009-02-05 Thread 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 dbou...@gmail.com 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)
 james.mcgov...@thehartford.com 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 sakim...@gmail.com
 Subject: Re: OpenID Security
 To: McGovern, James F (HTSC, IT) james.mcgov...@thehartford.com
 Cc: specs@openid.net
 Message-ID:
bf26e2340902050834ybf1ae5ara6b97aaac28cd...@mail.gmail.com
 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)
 james.mcgov...@thehartford.com 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 Mobile Profile?

2009-01-31 Thread 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 jernst+openid.net@
netmesh.us 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 jernst+openid.net@
 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


OpenID Mobile Profile?

2009-01-29 Thread 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: OpenID Mobile Profile?

2009-01-29 Thread 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 jernst+openid.net@
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/
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: CX proposal update

2009-01-22 Thread 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 a...@yahoo-inc.com 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 a...@yahoo-inc.com 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


CX proposal update

2009-01-13 Thread 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)

2009-01-11 Thread Nat Sakimura
I think so.

=nat

On Sun, Jan 11, 2009 at 8:14 AM, Breno de Medeiros br...@google.com 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 br...@google.comwrote:

 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 sakim...@gmail.com:
  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 drummond.r...@cordance.net
 
  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 n-sakim...@nri.co.jp
  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)

2009-01-06 Thread 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 drummond.r...@cordance.net

  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.netspecs-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 n-sakim...@nri.co.jp
 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

2009-01-02 Thread 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 record...@gmail.com 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 that a broad community can get behind!

 --David

 On Tue, Dec 30, 2008 at 9:03 PM, Nat Sakimura sakim...@gmail.com wrote:

 Hi Josh,

 To which statement did you agree?

 There has been a several things that has been pointed out, but I think I
 have answered to them.

 For example, for XML Sig, I have stated that this spec is not for XML,
 etc

Re: Request for consideration of Working Group Charter Proposal

2008-12-19 Thread 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 br...@google.com wrote:

 siiigh. That is what senility feels like.

 On Fri, Dec 19, 2008 at 12:39 PM, Allen Tom a...@yahoo-inc.com 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: Request for consideration of Working Group Charter Proposal

2008-12-19 Thread 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 sakim...@gmail.com 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 br...@google.comwrote:

 siiigh. That is what senility feels like.

 On Fri, Dec 19, 2008 at 12:39 PM, Allen Tom a...@yahoo-inc.com 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


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

2008-12-17 Thread 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


What is the status of AX 2.0 WG proposal?

2008-12-17 Thread 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


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

2008-12-17 Thread 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


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

2008-12-17 Thread Nat Sakimura
I am looking foward to it!

On Thu, Dec 18, 2008 at 12:00 PM, Dick Hardt dick.ha...@gmail.com 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 dick.ha...@gmail.com:

 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


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

2008-12-17 Thread 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 dick.ha...@gmail.com 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?

2008-12-17 Thread 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 sakim...@gmail.com wrote:

 I am looking foward to it!


 On Thu, Dec 18, 2008 at 12:00 PM, Dick Hardt dick.ha...@gmail.com 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 dick.ha...@gmail.com:

 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: What is the status of AX 2.0 WG proposal?

2008-12-17 Thread 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 sakim...@gmail.com 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 sakim...@gmail.com wrote:

 I am looking foward to it!


 On Thu, Dec 18, 2008 at 12:00 PM, Dick Hardt dick.ha...@gmail.comwrote:

 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 dick.ha...@gmail.com:

 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: A Working Groups Wiki Page

2008-12-16 Thread 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 br...@google.com wrote:

 On Thu, Dec 4, 2008 at 5:00 PM, Nat Sakimura sakim...@gmail.com 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 br...@google.com
 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 sakim...@gmail.com:
   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: Proposal to create the TX working group

2008-12-04 Thread 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 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

Re: A Working Groups Wiki Page

2008-12-04 Thread 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: PC Insurance Carriers

2008-12-04 Thread Nat Sakimura
That sounds interesting.

We have some member companies from PC 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 PC
 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

2008-12-04 Thread 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: Proposal to create the TX working group

2008-11-13 Thread 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 
 Drafthttp://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

Re: Proposal to create the TX working group

2008-11-12 Thread 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
Drafthttp://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], Clavid (Switzerland)
   Tatsuki Sakushima

Re: Proposal to create the TX working group

2008-11-09 Thread 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%29which
  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 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

Re: Proposal to create the TX working group

2008-11-08 Thread 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 
 procedureshttp://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

Re: Proposal to create the TX working group

2008-11-01 Thread 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 
 procedureshttp://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 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

Proposal to create the TX working group

2008-10-31 Thread 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] mailto:[EMAIL PROTECTED], Clavid
(Switzerland)
Tatsuki Sakushima, [EMAIL

Re: Backporting the 2.0 extension mechanism to 1.1

2008-08-13 Thread 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

2008-08-11 Thread 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:

 http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-02.html#anchor3
  
 


 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

2008-07-16 Thread 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: Proposal to create the PAPE working group

2008-05-22 Thread 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

 (iii)  Anticipated Contributions:  None.



 ___
 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: Login Federation

2008-02-20 Thread 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

2008-02-18 Thread 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

2008-02-04 Thread 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

2007-12-11 Thread 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: [Idschemas] identity schema element metadata: using existingspecifications

2007-09-09 Thread 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

2007-05-31 Thread 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 (x1) 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 employed
  whatsoever ...
 
 
 
 
  Johannes Ernst
  NetMesh Inc.
 
 
 
  ___
  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