[OpenID] Why use SREG instead of AX?

[Breno de Medeiros]

Great!

On Wed, Jul 15, 2009 at 12:09 PM, John Bradley <john.bradley at wingaa.com>wrote:

> I have done some work on the proposal.
> http://wiki.openid.net/ProposalForAURLSchemaRegistry
>
> I will fill in my proposal for the the process by the weekend.
>
> There would be a open list for people to make formal registry requests.
>
> The WG would have a list for people who have joined and made there IPR
> declaration.
> The proposal would have 4 weeks to get at-least three +1 votes.
> If it receives no -1 it would pass.
>
> If there are -1 votes then the chair of the WG would hold a vote on the
> list.
> Two thirds of the cast votes must be +1 to pass.
>
> There will be an experimental status using http://experimental.openid.net.
> People will need to specify if they are applying regular or Experimental.
> The Bar would be lower for experimental but the applicant would need to
> reapply yearly to keep it in the registry.
>
> John B.
>
>
> On 14-Jul-09, at 2:05 PM, Breno de Medeiros wrote:
>
>  Ping.
>>
>> On Fri, Jul 10, 2009 at 11:41 AM, John Bradley<john.bradley at wingaa.com>
>> wrote:
>>
>>> Breno,
>>>
>>> It's on my list for this weekend.
>>>
>>> I think Andrew's idea is a interesting solution.
>>>
>>> I don't think that overloading the <Type> attribute is a good long term
>>> solution.
>>>
>>> I hope we could do something better for XRD 1.0 discovery to describe the
>>> features of a OP.
>>>
>>> In the short term overloading <Type> is something we can do.
>>>
>>> The other pressing issues for AX are:
>>> 1 Registering a <Type> for discovering the RP privacy policy
>>> 2 Registering a <Type> for discovering the RP Terms of Service.
>>> 3 Having a way for the RP to know if the OP supports if_available.
>>>
>>> The last one is important to deal with the fact that some OP ignore
>>> if_available in requests and only give the user the choice to return the
>>> attributes that are requested as "REQUIRED".
>>>
>>> All the OPs could agree on a single way to interpret AX requests but that
>>> is
>>> a touch optimistic:)
>>>
>>> Having a way for a RP to differentiate between OPs operating on different
>>> theories would be good for RPs.
>>>
>>> John B.
>>> On 10-Jul-09, at 1:35 PM, general-request at openid.net wrote:
>>>
>>>  Date: Fri, 10 Jul 2009 10:00:05 -0700
>>>> From: Breno de Medeiros <breno at google.com>
>>>> Subject: Re: [OpenID] Why use SREG instead of AX?
>>>> To: Andrew Arnott <andrewarnott at gmail.com>
>>>> Cc: general at openid.net
>>>> Message-ID:
>>>>       <29fb00360907101000n77f57032wdd0635a60b660ff at mail.gmail.com>
>>>> Content-Type: multipart/alternative;
>>>>       boundary=0016369205b372e192046e5ce7b4
>>>>
>>>> --0016369205b372e192046e5ce7b4
>>>> Content-Type: text/plain; charset=ISO-8859-1
>>>> Content-Transfer-Encoding: 7bit
>>>>
>>>> For one, it would be interesting if someone with expertise on how to
>>>> create
>>>> lightweight processes for registration would clarify the language in
>>>> that
>>>> wiki document. Hopefully, it would be possible to define a process that
>>>> exempts the OIDF from the burden of having to impose the current IPR
>>>> policy
>>>> on each contributor. (I had hoped JBradley would take that on, but he
>>>> has
>>>> plenty on his hands at this point).
>>>> Once that wiki page is in good shape we could spam specs@ to bless it
>>>> and
>>>> then we can get started right away. There is even an initial
>>>> understanding
>>>> to use the domain name schemas.openid.net  and to host each registered
>>>> URL
>>>> at that domain with a description of the wire format for the attribute.
>>>> So
>>>> once this is up, I think progress could be made quickly.
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> --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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090715/13986595/attachment.htm>