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

2009-01-27 Thread Breno de Medeiros 
On Tue, Jan 27, 2009 at 6:46 PM, Breno de Medeiros  wrote:
> On Tue, Jan 27, 2009 at 6:30 PM, Allen Tom  wrote:
>> I agree with Martin. I believe that AX is the correct solution in the long
>> run, but given that there appears to be more SREG implementations currently
>> in the wild, we should update it to make it useful for sites that want to
>> use it.
>>
>> The other factor is that our lawyers feel very strongly that the user should
>> have the opportunity to read the RP's privacy policy before authorizing any
>> data exchange, and only SREG has the ability to do this automatically. The
>> alternative would be to use OAuth, and require RPs to pre-register with
>> Yahoo and provide their privacy policy and/or agree to a ToS before using
>> our OP.
>
> I think the AX proposing the WG is in agreement that AX 2.0 should support 
> this.

s/AX/folks/

>
>>
>> Allen
>>
>> Martin Atkins wrote:
>>>
>>> I agree that having both is not ideal, but I also feel strongly that we
>>> need to have a good SREG 1.1 spec because in practice today there are lots
>>> of SREG implementations and it is important to be able to interoperate with
>>> them even if in the long term we'd like to move to AX.
>>>
>>> This is, incidentally, why I was previously proposing forming an SREG
>>> group whose task is *only* to fix the spec to reflect current practice. This
>>> should encourage SREG interop in the short term while new developments to AX
>>> will encourage a move to AX in the longer term.
>>>
>> ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>
>
>
> --
> --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)
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

2009-01-27 Thread Breno de Medeiros 
On Tue, Jan 27, 2009 at 6:30 PM, Allen Tom  wrote:
> I agree with Martin. I believe that AX is the correct solution in the long
> run, but given that there appears to be more SREG implementations currently
> in the wild, we should update it to make it useful for sites that want to
> use it.
>
> The other factor is that our lawyers feel very strongly that the user should
> have the opportunity to read the RP's privacy policy before authorizing any
> data exchange, and only SREG has the ability to do this automatically. The
> alternative would be to use OAuth, and require RPs to pre-register with
> Yahoo and provide their privacy policy and/or agree to a ToS before using
> our OP.

I think the AX proposing the WG is in agreement that AX 2.0 should support this.

>
> Allen
>
> Martin Atkins wrote:
>>
>> I agree that having both is not ideal, but I also feel strongly that we
>> need to have a good SREG 1.1 spec because in practice today there are lots
>> of SREG implementations and it is important to be able to interoperate with
>> them even if in the long term we'd like to move to AX.
>>
>> This is, incidentally, why I was previously proposing forming an SREG
>> group whose task is *only* to fix the spec to reflect current practice. This
>> should encourage SREG interop in the short term while new developments to AX
>> will encourage a move to AX in the longer term.
>>
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
>



-- 
--Breno

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

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

2009-01-27 Thread Allen Tom 
I agree with Martin. I believe that AX is the correct solution in the 
long run, but given that there appears to be more SREG implementations 
currently in the wild, we should update it to make it useful for sites 
that want to use it.


The other factor is that our lawyers feel very strongly that the user 
should have the opportunity to read the RP's privacy policy before 
authorizing any data exchange, and only SREG has the ability to do this 
automatically. The alternative would be to use OAuth, and require RPs to 
pre-register with Yahoo and provide their privacy policy and/or agree to 
a ToS before using our OP.


Allen

Martin Atkins wrote:


I agree that having both is not ideal, but I also feel strongly that 
we need to have a good SREG 1.1 spec because in practice today there 
are lots of SREG implementations and it is important to be able to 
interoperate with them even if in the long term we'd like to move to AX.


This is, incidentally, why I was previously proposing forming an SREG 
group whose task is *only* to fix the spec to reflect current 
practice. This should encourage SREG interop in the short term while 
new developments to AX will encourage a move to AX in the longer term.



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

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

2009-01-27 Thread Allen Tom 

Breno -

I've updated the WG Charter to include patching SREG to include avatar 
image and info about the quality of the user's email address.


I also updated the charter to mention that AX will be updated to allow 
RPs to pass a link to their privacy policy.


http://openid.pbwiki.com/OpenID_Attribute_Exchange_Extension_2_0

Thanks
Allen


Breno de Medeiros wrote:


The only pertinent issue that is left open in this regard appears to
be whether or not SREG will be inspected as part of this. Allen,
please edit the WG proposal charter to include it.

On Mon, Jan 26, 2009 at 9:25 PM, Raghu Nallani Chakravartula
 wrote:
  

Futher, the verification information cannot sometimes be expressed in a
single type.
It may need to be qualified with additional information as regards who
verified it, when, how long is the verification valid etc...

I am guessing validation data exchange will need to grow into a struct
exchange.

-Raghu

Paul Madsen wrote:


FWIW, the separate 'verified' field is the approach the Infocard community
took

https://informationcard.net/wiki/index.php/Claim_Catalog

They also allow the particular verification method used to be listed


https://informationcard.net/wiki/index.php/Claim_Catalog#Verification_Methods

One drawback of this method is that all claims sent together get lumped
together into a single bucket wrt verification

paul

Martin Atkins wrote:
  

Henrik Biering wrote:


Agree!
If the range of SReg attributes is expanded, however, I would suggest to
add phone number (incl. quality as suggested for email) and possibly
street+city address line(s). That would make it possible to fill in a
somewhat larger part of typical registration forms.

  

It might be good to apply the quality thing to all of the fields.

One approach might be to add a "verified" argument that contains a list
of names of fields that the OP has verified in some way.

However, I think the SREG spec itself needs work done since the 1.1 draft
(that was never published) has a bunch of problems. It might be better to do
such work in a separate working group; I already have an updated 1.1 draft
with some of the problems from the current 1.1 draft fixed that could
potentially be used as a basis, though I'll need to dig it out since I'm not
sure what I checked it in to.

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




--
Paul Madsen
e:paulmadsen @ ntt-at.com
p:613-482-0432
m:613-282-8647
web:connectid.blogspot.com
ConnectID 


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

2009-01-27 Thread Paul Trevithick 
Paul, 

Yes, ICF Schema WG did introduce a Œverified¹ ³meta² claim. But it isn¹t
pretty. And it isn¹t without problems as you pointed out. The approach was
driven by sheer pragmatism. We had a card issuer who needed SOME way to
express this semantic, the ICF Schema WG doesn¹t play ³beat cop,² and the
solution had to work within the rather limiting ³flat² structure of i-card
claims. 

--PaulT


On 1/26/09 6:18 AM, "Paul Madsen"  wrote:

> FWIW, the separate 'verified' field is the approach the Infocard community
> took 
> 
> https://informationcard.net/wiki/index.php/Claim_Catalog
> 
> They also allow the particular verification method used to be listed
> 
> https://informationcard.net/wiki/index.php/Claim_Catalog#Verification_Methods
> 
> One drawback of this method is that all claims sent together get lumped
> together into a single bucket wrt verification
> 
> paul
>  
> 
> Martin Atkins wrote:
>> Henrik Biering wrote:
>>  
>>> Agree! 
>>> If the range of SReg attributes is expanded, however, I would suggest to add
>>> phone number (incl. quality as suggested for email) and possibly street+city
>>> address line(s). That would make it possible to fill in a somewhat larger
>>> part of typical registration forms.
>>>  
>>>  
>>  
>> It might be good to apply the quality thing to all of the fields.
>>  
>> One approach might be to add a "verified" argument that contains a list of
>> names of fields that the OP has verified in some way.
>>  
>> However, I think the SREG spec itself needs work done since the 1.1 draft
>> (that was never published) has a bunch of problems. It might be better to do
>> such work in a separate working group; I already have an updated 1.1 draft
>> with some of the problems from the current 1.1 draft fixed that could
>> potentially be used as a basis, though I'll need to dig it out since I'm not
>> sure what I checked it in to.
>>  
>> ___
>> specs mailing list
>> specs@openid.net
>> http://openid.net/mailman/listinfo/specs
>>  
>>  

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

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

2009-01-27 Thread David Fuelling 
+1

On Tue, Jan 27, 2009 at 3:33 PM, Dick Hardt  wrote:

> I'd prefer to narrow the scope of the WG and keep it focussed on a small
> number of goals.
>
> A separate WG on SREG would be preferred, but I think it is a disservice to
> the community to have two specs having such significant overlap.
> Choice in this case leads to confusion and reluctance to invest. The
> challenge is that those with an investment in SREG now have a propensity to
> see it continue on even though intellectually they can see the advantage of
> a unified spec.
>
> fwiw: I am in an off-site most of this week and won't be able to engage
> significantly until next week.
>
> -- Dick
>
>
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

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

2009-01-27 Thread Martin Atkins 

Dick Hardt wrote:
I'd prefer to narrow the scope of the WG and keep it focussed on a small 
number of goals.


A separate WG on SREG would be preferred, but I think it is a disservice 
to the community to have two specs having such significant overlap.
Choice in this case leads to confusion and reluctance to invest. The 
challenge is that those with an investment in SREG now have a propensity 
to see it continue on even though intellectually they can see the 
advantage of a unified spec.


fwiw: I am in an off-site most of this week and won't be able to engage 
significantly until next week.




I agree that having both is not ideal, but I also feel strongly that we 
need to have a good SREG 1.1 spec because in practice today there are 
lots of SREG implementations and it is important to be able to 
interoperate with them even if in the long term we'd like to move to AX.


This is, incidentally, why I was previously proposing forming an SREG 
group whose task is *only* to fix the spec to reflect current practice. 
This should encourage SREG interop in the short term while new 
developments to AX will encourage a move to AX in the longer term.


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

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

2009-01-27 Thread Dick Hardt 
I'd prefer to narrow the scope of the WG and keep it focussed on a  
small number of goals.


A separate WG on SREG would be preferred, but I think it is a  
disservice to the community to have two specs having such significant  
overlap.
Choice in this case leads to confusion and reluctance to invest. The  
challenge is that those with an investment in SREG now have a  
propensity to see it continue on even though intellectually they can  
see the advantage of a unified spec.


fwiw: I am in an off-site most of this week and won't be able to  
engage significantly until next week.


-- Dick

On 26-Jan-09, at 9:34 PM, Breno de Medeiros wrote:


Let's please maintain the discussion on this thread on definition of
the scope of the WG. Once the WG is formed, the technical aspects can
be discussed there.

The only pertinent issue that is left open in this regard appears to
be whether or not SREG will be inspected as part of this. Allen,
please edit the WG proposal charter to include it.

On Mon, Jan 26, 2009 at 9:25 PM, Raghu Nallani Chakravartula
 wrote:
Futher, the verification information cannot sometimes be expressed  
in a

single type.
It may need to be qualified with additional information as regards  
who

verified it, when, how long is the verification valid etc...

I am guessing validation data exchange will need to grow into a  
struct

exchange.

-Raghu

Paul Madsen wrote:


FWIW, the separate 'verified' field is the approach the Infocard  
community

took

https://informationcard.net/wiki/index.php/Claim_Catalog

They also allow the particular verification method used to be listed


https://informationcard.net/wiki/index.php/ 
Claim_Catalog#Verification_Methods


One drawback of this method is that all claims sent together get  
lumped

together into a single bucket wrt verification

paul

Martin Atkins wrote:


Henrik Biering wrote:


Agree!
If the range of SReg attributes is expanded, however, I would  
suggest to
add phone number (incl. quality as suggested for email) and  
possibly
street+city address line(s). That would make it possible to fill  
in a

somewhat larger part of typical registration forms.



It might be good to apply the quality thing to all of the fields.

One approach might be to add a "verified" argument that contains  
a list

of names of fields that the OP has verified in some way.

However, I think the SREG spec itself needs work done since the  
1.1 draft
(that was never published) has a bunch of problems. It might be  
better to do
such work in a separate working group; I already have an updated  
1.1 draft
with some of the problems from the current 1.1 draft fixed that  
could
potentially be used as a basis, though I'll need to dig it out  
since I'm not

sure what I checked it in to.

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




--
Paul Madsen
e:paulmadsen @ ntt-at.com
p:613-482-0432
m:613-282-8647
web:connectid.blogspot.com
ConnectID 


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



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





--
--Breno

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


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