[OIDFSC] OpenID Artifact Binding Working Group Proposal

Nat Sakimura sakimura at gmail.com
Sat Feb 6 09:45:10 UTC 2010


On Sat, Feb 6, 2010 at 1:17 AM, John Bradley <john.bradley at wingaa.com>wrote:

> The idea is to have the binding backwards compatible with the existing
> GET/POST binding.
>
> The artifact binding would be initiated by the RP if they support it.  A
> IdP not supporting artifact would process it according to the existing spec.
>
> It is the large IdP that want it due to problems with POST. (mobile aside)
>   However it is not useful unless RP's implement it.
>
> I agree that wide spread RP adoption is more likely if it is part of the
> core spec.
>
> I know that CX and other people are proceeding with implementations.
>

Actually, not. We are just doing POC implementation to see the compatibility
issues etc. with the current libraries.
CX actually does not depend on any binding. It can be used over POST
binding, which we know of as Authn 2.0, as well.
Its dependency is not on AB but on AX1.1: being able to send a parameter
with a request.


>
> My worry is that if we do nothing we will wind up with one or more defacto
> standards for artifact.
>

Indeed. While NRI was the only one that was implementing it, I did not care
too much since we could switch to the standardized version whenever it comes
up. However, I have started to see some ad-hoc implementations, which are
beyond my control. If we do not standardize it now, we will lose the game.


>
> I am also slightly concerned that some of the people involved have existing
> implementations that they are backing.
>

I do not know about others, but do not worry about ours.
As far as AB is concerned, it is POC, out of my own R&D project, and is not
in the production environment.
As I wrote above, timing seems to be more important. Real big implementors,
when they see business chance,
will not wait for us.


>
> Prototypes are good but frankly presenting a finished spec to be rubber
> stamped is something I have seen other places.
> (you know who I am talking about MS)
>

;-)


>
> In this case I think people have proceeded independently because they could
> not get this WG started.
>
> I do think the WG needs to consider all of the design options for adding
> this.
>
> John B.
> On 2010-02-05, at 1:07 PM, David Recordon wrote:
>
> I'm really weary of making non-compatible protocol changes
> as separate efforts.  If this is going to be done then it should happen
> within the context of the main specification.
>
> Personally I'm worried about the additional complexity given a relatively
> narrow group of implementors calling for the feature.
>
> --David
>
> On Fri, Feb 5, 2010 at 4:01 PM, John Bradley <john.bradley at wingaa.com>wrote:
>
>> This creates a new direct message type.   I thought extensions were
>> extending the existing messages.
>>
>> It is probably a grey area.
>>
>> Other protocols consider this to be a separate protocol binding rather
>> than an extension of the redirect or POST binding.
>>
>> John B.
>>
>>
>> On 2010-02-05, at 12:23 PM, David Recordon wrote:
>>
>> Hey Nat,
>> Shouldn't this be considered an extension?
>>
>> --David
>>
>> On Fri, Feb 5, 2010 at 2:54 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>>
>>> *OpenID Artifact Binding Working Group*
>>> ------------------------------
>>>  *Charter Proposal*
>>> In accordance with the OpenID Foundation IPR policies and procedures this
>>> note proposes the formation of a new working group chartered to produce an
>>> OpenID specification. As per Section 4.1 of the Policies, the proposed
>>> charter is below.
>>> ------------------------------
>>>  *I. Name*
>>> Artifact Binding Working Group (AB)
>>> ------------------------------
>>>  *II. Statement of Purpose*
>>> Produce a binding of OpenID requests and response (assertion) that uses
>>> direct communication for main payload and indirect communication for a small
>>> reference data called Artifact to cope with long URL limits experienced by
>>> man
>>> ------------------------------
>>>  *III. Scope*
>>> Create the Artifact Binding to support the identified needs. Currently
>>> identified:
>>>
>>>    - Cope with long url problem, especially for mobile browsers.
>>>    - Cope with the security problems of non-encrypted payload to go
>>>    through the user agents which may act as a man-in-the-middle.
>>>
>>> ------------------------------
>>>  *IV. Specifications*
>>> OpenID Artifact Binding 1.0
>>> ------------------------------
>>>  *V. Anticipated audience*
>>> All those interested in using OpenID in mobile and other constrained
>>> browser and server elements.
>>> ------------------------------
>>>  *VI. Language of business*
>>> English.
>>> ------------------------------
>>>  *VII. Method of work*
>>> Mailing list discussion. Posting of intermediate drafts in the OpenID
>>> Wiki. Virtual conferencing on an ad-hoc basis.
>>> ------------------------------
>>>  *VIII. Basis for completion of the activity*
>>> The Artifact Binding 1.0 spec made final.
>>> ------------------------------
>>>  *Background Information*
>>> ------------------------------
>>>  *I. Related Work*
>>> SAML Artifact Binding
>>> OAuth
>>> Wrap
>>> Contract Exchange
>>> ------------------------------
>>>  *II. Initial Membership*
>>>
>>>    - Breno de Medeiros, breno at google.com. Google, Inc.
>>>    - Hideki Nara, hdknr at ic-tact.co.jp, Tact Communications
>>>    - Nat Sakimura, n-sakimura at nri.co.jp, Nomura Research Institute, Ltd.
>>>     (editor)
>>>    - John Bradley, ve7jtb at ve7jtb.com
>>>    - Allen Tom, atom at yahoo-inc.com, Yahoo!
>>>    - Will Norris, will at willnorris.com
>>>
>>> ------------------------------
>>>  *III. Expected contribution*
>>>
>>>
>>> Draft: OpenID Artifact Binding 1.0 - Draft 01,
>>> http://www.sakimura.org/specs/ab/1.0/
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> http://www.sakimura.org/en/
>>> http://twitter.com/_nat_en
>>>
>>
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100206/4d8b5e64/attachment.htm>


More information about the specs mailing list