Requirements discussion of OpenID Future

[John Bradley]

We didn't go into the details on that call.

I was saying that the Web server flow we selected for the AB extension used direct communications from a client with a shared secret to retrieve the assertion.
We used JSON Magic Signature to provide a asymmetric signature over the assertion by the OP.

It was pointed out that a new proposal for asymmetric signatures has been added to OAuth 2.0.   

I said that if that if that is appropriate it should be used instead of JSON Magic Signature for consistency with OAuth 2.0

Given the new signature method being accepted and appropriate you are close to being able to do a LoA 3 authentication on top of the OAuth Web Server flow.

That is not to say that other flows would have the same characteristics.

We discussed that the Agent flow doesn't require any authentication by the RP to the OP to receive a token.
I don't think that flow as proposed could meat LoA 2.    It may not meet LoA 1 the use of iFrames to pass information in the browser needs to be looked at from a security point of view.   The existing approved schemes all use redirect or POST.

Nat and I are proposing a IA to OAuth 2 to add a request by reference option.  That with a encrypted/audience restricted token for the response would likely allow the agent profile to be used at higher LoA.

So yes the OAuth 2.0 agent profile and other multi leg profiles are not 90% done as far as higher LoA, or perhaps any LoA.

At LoA 3 there is also the question of what the signature must cover for non repudiation.

In pure OAuth 2.0 if only the access token is signed,  and you use that to access a endpoint that asserts an Identity and other attributes to determine the identity that may be a slick solution, but not meet the non-repudiation requirements.

The authors of SP-800-63 were thinking that the assertion would always include an identifier and other time and authorization information like asserted LoA that is signed by the IdP in a way that cannot be repudiated later.

The non-repudiation aspect of LoA 3 is a technical requirement for legal reasons as opposed to security reasons.   
In AB Nat and I made sure that the required elements were signed as part of the assertion that contained the access token.
Whatever the access token was used to retrieve was out of scope.   Much like a SAML attribute query would be in conjunction with a SAML LoA 3 authentication.

So not all of the issues for all of the flows for OIC are sorted out.

Nat and I have a proposal for higher LoA in AB based on the web server flow, that mostly leverages the underlying OAuth security.

It may be that OIC defines multiple flows and the Agent flow is not appropriate for higher LoA.

These things need further discussion in a Work Group.

John B.




On 2010-06-23, at 2:03 AM, Anthony Nadalin wrote:

>> 9) Higher LOA -According to John Bradley, 90% of the work required to implement higher LOA is already in OAuth2
> 
> So OAuth doesn't accommodate for multi-leg issuance (both for the access grant and the access request). This may be an issue as some tokens could be provisioned out-of-band, also may need  write a new profile defining efficient encoding for token format (e.g., to simplify parsing and include them in URLs). So I don't think that this is a done deal and this would mean getting this work done now in OAuth
> 
> -----Original Message-----
> From: openid-specs-bounces at lists.openid.net [mailto:openid-specs-bounces at lists.openid.net] On Behalf Of Allen Tom
> Sent: Monday, June 21, 2010 6:58 PM
> To: OpenID Specs Mailing List
> Subject: Requirements discussion of OpenID Future
> 
> Hi All,
> 
> There¹s been a lot of discussion the past few weeks around specific technical proposals focused on moving OpenID forward. We wanted to take a step back and make sure that we understand the problems that there are broad consensus around solving over the next six to nine months. While there has also been some discussion around use cases and charters, there hasn¹t yet been broad consensus.
> 
> Today Yahoo!, Google, and Facebook met with some of the authors of Artifact Binding, the OpenID Connect proposal, and OAuth 2.0 to discuss our specific future requirements.  We put together a summary document of 20+ items that we would like to see and wanted to start a discussion around them.  Today helped to verify our instinct that we could achieve these OpenID goals by layering features on top of OAuth 2.0 while specifically maintaining the decentralized nature of OpenID.
> 
> After this discussion it seems that the Connect work group charter can encompass this work and thus provides a mailing list and IPR policy to work on these items. Facebook, Google, and Yahoo! expect to be able to sign the contributor agreements for the OpenID Connect working group relatively soon.
> 
> We hope that other OpenID community members and organizations will provide feedback on how this list compares to their needs and/or get involved in flushing out the technical details.
> 
> Here's the list of features that we would like to see implemented in a future version of OpenID:
> 
> http://wiki.openid.net/Future-OpenID-Technical-Requirements
> 
> Feedback and discussion is more than welcome!
> 
> Allen
> 
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
> 
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs