Agreed with Allen, let's modernize SREG so that the spec matches how
people are using it already with 2.0 though point people to using AX
instead. I'd prefer this happen within the same WG.
--David
On Feb 3, 2009, at 3:20 PM, Allen Tom wrote:
Hi Dick,
I'll be happy to add language to the
Nat,
My apologies then. I did not understand what you meant and I wrote poor
language in the scope description. Moreover, what you are describing is
probably something that would fit much better in this working group.
Someone wants a stab at clarifying the proposal on this point?
2009/2/3 Nat
CX does not and cannot carry information from multiple users.
The information model deals exclusively around a single subject.
=...@tokyo via iPhone
On 2009/02/04, at 7:50, Dick Hardt wrote:
Thanks for the feedback Breno!
Nat: can you provide some illumination? I see that CX would define
=...@tokyo via iPhone
On 2009/02/04, at 7:39, Breno de Medeiros wrote:
On Tue, Feb 3, 2009 at 2:19 PM, Dick Hardt
wrote:
1) I'd prefer to NOT include SREG in the work, but am ok with it
being in if the scope is really to clarify issues in SREG and add
language directing people to AX
Hi Dick,
I'll be happy to add language to the revised SREG spec to strongly
encourage all new deployments to use AX and to NOT use SREG, however,
given the current popularity of SREG, I think it's a good idea to
clarify and modernize it a bit. Speaking on behalf of Yahoo, once we
have a usab
Thanks for the feedback Breno!
Nat: can you provide some illumination? I see that CX would define attribute
types to be carried in AX. I'm confused about the scenario where information
from multiple users would be transmitted as that implies that the protocol no
longer is dealing with a single
On Tue, Feb 3, 2009 at 2:19 PM, Dick Hardt wrote:
> 1) I'd prefer to NOT include SREG in the work, but am ok with it being in
> if the scope is really to clarify issues in SREG and add language directing
> people to AX. Anyone else have a strong opinion either way? (SREG included
> in this WG or
1) I'd prefer to NOT include SREG in the work, but am ok with it being in if
the scope is really to clarify issues in SREG and add language directing people
to AX. Anyone else have a strong opinion either way? (SREG included in this WG
or in a different one?)
2) In the Scope section, I feel str
Yes. As far as the protocol flow is concerned, that flow is exactly
what I have suggested in an earlier mail.
By the way, have you thought of some way of dynamically establishing
consumer_key & consumer_secret?
I envision that both consumer and provider advertising its identifier
as in XRD and a
