Hi John,
Ah! I think it is so called "Framing Problem".
When I modified the 2.0 spec to create this 2.1 draft 0.001, I have
removed all the restrictions that authentication messages have to be
indirect. So, now, it can be direct as well. When using direct, to
link it with user action, the artifact is used.
See inline:
On Thu, Aug 20, 2009 at 1:52 AM, John Bradley
<[email protected]> wrote:
Hi Nat,
inline
On 19-Aug-09, at 12:32 PM, Nat Sakimura wrote:
Hi John,
Inline:
On Wed, Aug 19, 2009 at 10:30 PM, John Bradley <[email protected]
> wrote:
Nat,
On a first read through.
Your proposal only solves half the problem, in that it only reduces
the size of the indirect response. With extensions it is still
possible to likely that requests will go over 2K.
Why is that so?
All the extensions can use this direct communication path.
What was sent over indirect communication is sent over direct
communication.
If the full request must be made indirectly that doesn't reduce the
request size.
As stated above, the full request can be made directly. In that
case, only artifact and a few others moves indirectly. Thus, it will
reduce the request size drastically, putting upper bound for the
indirect request size.
Are you thinking that the authentication is done via a indirect
request but CX, AX etc all happen via direct communications?
No. Main body of Authentication request, and thus extension
requests, are sent via direct request and only the artifact and a
few others are sent via indirect communications.
Unless you send the attributes that are going to be requested in the
indirect request how would the user provide consent to release them
to the RP?
The request is sent from the RP to the OP over the direct
communication. Then, the user is taken from the RP to the OP over
the indirect communication carrying the Artifact. The OP, upon
receipt of the Artifact, can reconstruct the main request from it.
Then, the user consent etc. happens as usual. Then, instead of the
OP sending the positive assertion back to the RP, it sends the
Artifact and the user back to the RP over the indirect communication
signifying that it has completed the processing at the OP. Using the
Artifact, the RP fetches the (+ve or -ve) assertion from the OP
through the direct communication. Verification etc. goes on then as
usual there after.
Also openID relies on validating the users presence via a cookie.
That would not be available to the OP in a direct session.
Hopefully now you see why it works. It changes almost nothing. It
just pushes the main payload to the direct communication and that's
it. Others do not change.
I would prefer not to have to revisit this again once the request
size becomes an issue.
The OP needs to advertise that it supports the binding in it's XRD/S.
In this draft, I made the support of direct communication mandatory
and the version of the OpenID Authn protocol was raised to 2.1. This
is advertising that it supports the binding in its XRD/S.
I don't know that making it mandatory is necessarily a good idea.
There may be other things in 2.1 that may be useful aside from a
artifact binding.
I prefer the idea that a OP could optionally support the binding and
it would be discoverable.
I don't feel super strong about it, but others may.
Right. I just wanted to be a minimalist and also wanted the spec to
be fairly symmetric. If the artifact is to be an optional binding,
then it would have to define a new type URI. However, from the sake
of being symmetric, then, we should define type URI for the indirect
binding as well and list it on XRD/S.
As you point out this doesn't do anything for security. The
artifact will need to be encrypted or mutual TLS used for the direct
connection.
The encryption of the Artifact is an open question, as SAML Artifact
binding does not encrypt the Artifact either siting that in this
limited size that the encryption is unpractical.
For the mutual authentication, I could incorporate relevant sections
of CX here as well. That will make the already thin CX spec even
thinner.
You are going to make me read CX aren't you:)
Yes. If you leave the contract schema alone, then it is extremely
concise.
In testing something close to 1% of RP and OP have TLS implemented
correctly now. Mutual TLS may impossible to implement in some
environments.
It is easy to say just use TLS for that, and make it someone else's
problem. Mutual TLS may be the best option but encrypting the
fragment and using normal TLS should also be considered.
Having the OP POST to the RP directly should also be considered,
that would work for LoA 2 but probably not LoA 3 without mutual TLS.
That's unsolicited direct response, and it is not precluded in this
draft.
No unsolicited assertions are still indirect.
As I have explained above, in this draft, unsolicited assertions can
be direct. It may have no association with the user session as well.
If it does, then the user has to be at the OP to start with, and the
User has to be taken to the RP with the Artifact.
I was thinking of a flow where the OP makes two replies one indirect
and the other direct.
That is exactly what is in my draft, though the indirect one is
optional.
The main reason not to do this is that it would not work with RP
load balancing. Likely they go to different servers.
We have that problem now with nonces.
I think this is an implementation problem.
The implementation should have some kind of shared storage behind
the server farm and store the direct response to with the Artifact
as the key. When the user landed on one of the server, the server
can pull the data from the shared storage, and that's it.
Note that the unsolicited direct response without user being taken
back to the RP works. It works for AX update etc.
Also, I have constructed the protocol to be "easier to implement"
for RPs.
If they do not support unsolicited direct response, that is still OK.
It is only this feature that uses the OP to the RP communication
unlike SAML's case.
It is always the RP making request to the OP.
Artifact binding is simple in principle but the devil is in the
details.
Is there anything else?
We can create an issue tracker and solve them one by one.
I actually do not foresee too many of them.
Also, we should not try to solve all the use cases.
Being able to satisfy 90% of them should be good enough.
John B.
There are a number of tradeoffs with different methods.
A good attempt to show how this method would work.
John B.
On 19-Aug-09, at 5:51 AM, Nat Sakimura wrote:
Been sick and not following the various discussion around artifact
since last Saturday, so I might be out of sync but here is my shot
for Artifact Binding which I hoped to provide on Friday 14th.
http://wiki.openid.net/OpenIDwithArtifactBinding
It is about 40 lines of modification/addition. The portion that I
changed/added are in RED so it should be easy for you to find out.
Its sequence is a bit different than SAML Artifact binding as I
tried to minimize the impact to the current deployments.
It has done nothing about encryption. The direct communication
should be over the verified TLS channel. Security implication of the
Artifact exposure on the indirect communication should be further
discussed, but my preliminary assessment is that it should be ok.
=nat
On Wed, Aug 19, 2009 at 8:42 AM, Dick Hardt
<[email protected]> wrote:
my $0.02
I expect the data moving between the RP and OP to become even larger
over time, therefore a standard, alternative mechanism for moving
the data directly between the RP and OP, particularly when bandwidth
to the client is constrained, seems desirable.
I would generally prefer a proven, widely deployed encryption
mechanism such as TLS rather then adding functionality to OpenID
-- Dick
________________________________________
From: [email protected] [[email protected]
] on behalf of John Bradley [[email protected]]
Sent: Tuesday, August 18, 2009 3:27 PM
To: Allen Tom
Cc: [email protected]
Subject: Re: Artifact Binding Re: specs Digest, Vol 36, Issue 1
One of the things you need for LoA 2 is to prevent eavesdropping.
The choices are encrypt the response to the RP or use direct
communication with TLS (probably mutual) if the RP is going to make a
direct request to the OP.
Using an artifact binding has advantages and disadvantages. Using it
to get around the 2K URI limit in IE would put any RP not supporting
it at a disadvantage.
It might be acceptable if the RP could indicate its support for
artifact binding in the request and allow the OP to use artifact
instead of post.
With mobile devices becoming more common I can see people preferring
an artifact binding over the existing ones.
It is a real change to the protocol and will add complexity supporting
another binding.
One short term fix that Andrew Arnott implemented in DotNetOpenAuth is
a smart detection of OP's support for AX vs SREG and preferring SREG
if it is supported. Most people are only using AX for the SREG
attributes anyway.
I agree that the AX attribute URI need to get sorted out anyway. We
could look at making them shorter when we mint new standard ones.
John B.
On 18-Aug-09, at 6:02 PM, Allen Tom wrote:
> Hi All,
>
> Sorry for the delayed response, I'm still catching up on mail after
> being on vacation last week.
>
> Breno - How would artifact binding help OpenID attain Loa2? I'm
> unclear as to how that would make a difference.
>
> The Yahoo OP was recently updated to return responses that are
> larger than 2KB using POST, and this has caused many users to see
> the ugly browser warning because most RPs don't support HTTPS.
> Displaying the ugly browser warning is really unacceptable, so we'll
> probably update the Yahoo OP to only use POST only for HTTPS
> return_to URLs.
>
> The excessively large responses are mostly due to AX being
> excessively verbose. It would be really nice if we could revise AX
> to be a lot more compact. Perhaps if we had a standardized AX
> schema, we'd be able to shorten the message size.
>
> Allen
>
>
>
> Breno de Medeiros wrote:
>>
>> Since Google was mentioned here as wanting artifact, let me make
the
>> record clear to say that I spoke about artifact binding on my
>> personal
>> capacity.
>>
>> My very own personal view is that an artifact profile would be easy
>> to
>> spec out (the check_authentication or stateless mode is already the
>> artifact flow without the additional benefits of artifact) and
would
>> make OpenID more robust. Currently long URLs require POST which
only
>> gives you so much mileage. POST is ugly if the RP has a non-HTTPS
>> endpoint, with scary user confirmation dialogs.
>>
>> Also, I did not wish to express any personal opinion on whether
>> OpenID
>> should seek Loa2, just to note that artifact is the easiest route
>> there.
>>
>> On Thu, Aug 13, 2009 at 10:45 AM, Nat Sakimura<[email protected]>
>> wrote:
>>
>>> John,
>>> You changed the topic of this thread.
>>> This thread was about artifact binding, not about Government LoA.
>>> That's another thread :-)
>>> Yes, Artifact helps LoA, but it is not only that.
>>> It helps the mobile space immensely.
>>> =nat
>>>
>>> On Fri, Aug 14, 2009 at 2:00 AM, John Bradley <[email protected]>
>>> wrote:
>>>
>>>> Chris
>>>> I think we are agreeing. OpenID needs to play to it's strengths.
>>>> Chasing shiny things is tempting.
>>>> We need to carefully consider the impact of changes.
>>>> That is not to say that openID shouldn't evolve.
>>>> There are always tradeoffs.
>>>> Remember that a GSA LoA 2 or 3 profile is focused on the Gov
>>>> accepting the
>>>> assertions for specific uses.
>>>> Other people are free to make there own determinations for other
>>>> use
>>>> cases.
>>>> I am interested in finding out if IdP really want to be certified
>>>> at LoA 2
>>>> with all of the extra identity
>>>> proofing, liability and other things that go with that.
>>>> A LoA 2 certification for a IdP involves a lot more than just
>>>> tweaking
>>>> some protocol peaces.
>>>> Are there OPs that want that?
>>>> John B.
>>>> On 13-Aug-09, at 9:11 AM, Chris Messina wrote:
>>>>
>>>> On Thu, Aug 13, 2009 at 8:34 AM, John Bradley <[email protected]>
>>>> wrote:
>>>>
>>>>> Some may ask if we add artifact binding, signatures and
>>>>> encryption are we
>>>>> not reinventing SAML Web SSO, or something of equal complexity?
>>>>>
>>>> I would like to know more about this, but my instinct is always
>>>> to say
>>>> "NO" for as long as possible when any new feature will a)
introduce
>>>> complexity and b) stifle or impair potential adoption.
>>>> That we've come as far as we have is a feat; maintaining that
>>>> momentum is
>>>> critical — and that means making good on the promise of what
>>>> OpenID offers
>>>> *today* — and only extending it with real world examples where
>>>> people are
>>>> implementing kludges (en masse) to serve a common need.
>>>>
>>>> Chris
>>>> --
>>>> Chris Messina
>>>> Open Web Advocate
>>>>
>>>> Personal: http://factoryjoe.com
>>>> Follow me on Twitter: http://twitter.com/chrismessina
>>>>
>>>> Citizen Agency: http://citizenagency.com
>>>> Diso Project: http://diso-project.org
>>>>
>>>> OpenID Foundation: http://openid.net
>>>>
>>>>
>>>> This email is: [ ] bloggable [X] ask first [ ] private
>>>>
>>>>
>>>> _______________________________________________
>>>> specs mailing list
>>>> [email protected]
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> http://www.sakimura.org/en/
>>>
>>> _______________________________________________
>>> specs mailing list
>>> [email protected]
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>>
>>>
>>
>>
>>
>>
>
> _______________________________________________
> specs mailing list
> [email protected]
> http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
