Re: OPs to advertise support for OpenID extensions via the extension's type URI

[Allen Tom]

+1

Allen


Breno de Medeiros wrote:
I agree with Andrew on this suggestion. I don't think the UI WG 
proceeded differently for any particular reason, except that no such 
convention existed and we were not aware of side-effects previously. 
Regardless of interoperability issues with existing libraries, I 
thinking having a type URI for the extension is desirable from purely 
semantic standpoint (if a human were to read such document, it would 
be more logically organized with 'umbrella' type URIs for the extension).


On Wed, Jul 22, 2009 at 4:57 PM, Andrew Arnott > wrote:


Hi folks,

Breno just pointed out to me that the UI extension's draft spec,
Discovery section
 calls
out two type URIs that should appear in an OpenID identifier's
XRDS document.  But neither of these type URIs is the type URI of
the extension itself.

DotNetOpenId and DotNetOpenAuth both take for granted that an
extension's primary type URI (the one that appears at the value of
the openid.ns./someext/ parameter) is expected to appear in an
XRDS document if the OP supports that extension.  Maybe that
wasn't a spec'd out behavior for OpenID extensions, but it seems
to hold true for the OPs I tested at the time. 


While it's neat to see the UI extension include a specific
Discovery section that allows OPs to declare their support for the
different parts of the extension, there's no mention of declaring
the extension itself.  As a result, RPs (at least the ones based
on DNOI/DNOA) may not think that an OP supports the UI extension
when in fact it does.  


So I'm requesting two things:

   1. Can we get the UI extension DRAFT spec updated to include
  that the http://specs.openid.net/extensions/ui/1.0 URI be
  included in the XRDS document?
   2. Can we standardize on the idea that an extension's type URI
  should be in an XRDS document if the OP supports it so that
  RPs can easily scan for all supported extensions? (this
  would be in addition to any additional type URIs the
  extension wants to define and advertise)

What do you all think?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to
the death your right to say it." - S. G. Tallentyre

___
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

Clarification needed in PAPE spec

[Allen Tom]

Another ambiguous parameter is the openid.pape.preferred_auth_policies 
request parameter in section 5.1.


The first sentence in Section 5.1 says that all the request parameters 
are mandatory (MUST be included), however the description  
openid.pape.preferred_auth_policies says that zero policies can be 
specified. Is there a special value for "zero policy"?  Or should the 
parameter be omitted if the no policy is requested?


http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html#anchor8

Thanks

Allen

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

Typo in the PAPE spec?

[Allen Tom]

Hi All,

In Section 5.1 of the PAPE Spec, there's a request parameter defined called
 
   openid.pape.preferred_auth_level_types


however the example in the same section calls it

openid.pape.preferred_auth_levels

Which one is it?


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

Re: OAuth Hybrid and UI ML?

[Allen Tom]

Hi David,

I can take care of moderating the UI mailing list. Am I responsible for 
collecting the contribution agreements myself?


Allen


David Recordon wrote:
Once the working groups are approved and someone is willing to 
moderate new members on the list to make sure they've signed 
contribution agreements before posting, I can make the list itself.


--David

On Jun 11, 2009, at 6:21 PM, Allen Tom wrote:


Hi Nat,

How does one create a mailing list? At least with regards to the 
OpenID UI WG, we're just mailing each other directly.


Allen



Nat Sakimura wrote:
Hi. 

I just found out that the Mailing list for OAuth Hybrid WG and UI WG 
are not listed on http://openid.net/mailman/listinfo/ .  
<http://openid.net/mailman/listinfo/>


To make sure equal participation, we should make it possible for 
people to find out about them. 

Are they established at all? Where is the discussion being conducted 
right now? 


--
Nat Sakimura (=nat)
http://www.sakimura.org/en/


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


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




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

Re: OAuth Hybrid and UI ML?

[Allen Tom]

Hi Nat,

How does one create a mailing list? At least with regards to the OpenID 
UI WG, we're just mailing each other directly.


Allen



Nat Sakimura wrote:
Hi. 

I just found out that the Mailing list for OAuth Hybrid WG and UI WG 
are not listed on http://openid.net/mailman/listinfo/ .  



To make sure equal participation, we should make it possible for 
people to find out about them. 

Are they established at all? Where is the discussion being conducted 
right now? 


--
Nat Sakimura (=nat)
http://www.sakimura.org/en/


___
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: [OpenID] Signing method for XRD

[Allen Tom]

+1


John Panzer wrote:


So, +1 for the simplest form of signing that could possibly work.



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

Re: [OpenID] Signing method for XRD

[Allen Tom]

Hi Nat,

Generating signatures is tricky, and XMLDSig is trickier than most. That 
being said, there are libraries that do it, and they do seem to work.


First of all, I'd be happier to see something other than XML, but if XML 
has already been decided on, then I would not mind seeing something 
other than XMLDSig, if the alternative is significantly for developers 
to generate than XMLDSig.


Allen

Nat Sakimura wrote:

Hmmm.

Perhaps I did not spell my intent in the original mail well enough.

My question was:

(1) Is XML DSig easy enough for you developers to use?
(2) Is XML DSig supported in your environemnt?
   e.g., Google AppEngine, Force.com, your hosting environment, 
your own server, etc.
(3) If either (1) or (2) is negative, are you aimiable to use a very 
simple alternative to it,

   or you do not bother signing XRD at all?

Best,

=nat

On Thu, Jun 11, 2009 at 4:16 AM, Santosh Rajan > wrote:



I agree that in XML they are not equivalent. Yes but the signing
process
itself is binary, it has nothing to do with text or its meaning.


Hans Granqvist wrote:
>
>> Once you digitally sign a document, though physically the document
>> remains
>> in tact and retains its content type, after the act of signing,
it is
>> really
>> a frozen bunch of bits. And if you dont make that distinction
you get
>> into
>> all sorts of tangles. And that was the mistake made by XMLDSig.
In other
>> words after signing the Content-Type should be binary, whatever
you want
>> to
>> call it. After verification it takes up its original Content-Type.
>
> In XML these two are equivalent:
>
>
>
>
>
> A signing process needs to understand this, and that is what XML
Dsig
> does.
> XML was not defined to be a wire format.
>
> Hans
> ___
> general mailing list
> gene...@openid.net 
> http://openid.net/mailman/listinfo/general
>
>


-

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com
--
View this message in context:
http://www.nabble.com/Signing-method-for-XRD-tp23956678p23969137.html
Sent from the OpenID - General mailing list archive at Nabble.com.

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




--
Nat Sakimura (=nat)
http://www.sakimura.org/en/


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


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

Re: Are the Discovery Components Done Enough? (Fwd: [security] OpenID Security Best Practices Doc)

[Allen Tom]

My primary concern with changing OpenID Discovery is the upgrade path to 
the new discovery mechanism. It took way too long for everyone to 
upgrade to OpenID 2.0, so I'd like to have a better understanding the 
upgrade path to OpenID 2.1 and/or the new Discovery mechanism.


Allen


David Recordon wrote:

Hey David,
I've been following some of the discovery work the past few months, 
but don't have a clear picture if the various components are actually 
solid enough to begin working with.  I know XRD is moving forward, but 
what's the state of site-meta 
(http://tools.ietf.org/html/draft-nottingham-site-meta-01) 
<http://tools.ietf.org/html/draft-nottingham-site-meta-01%29> or now 
WebFinger (http://code.google.com/p/webfinger/)? 
<http://code.google.com/p/webfinger/%29?>  Is there something in 
WebFinger which wouldn't solve OpenID discovery entirely?


These questions and the lack of adoption of XRD, site-meta or 
completion of WebFinger have all contributed to my belief that we're 
still just not ready to redefine how OpenID's discovery process should 
work.


Thoughts?

Thanks,
--David

Begin forwarded message:


*From: *David Fuelling mailto:sappe...@gmail.com>>
*Date: *June 9, 2009 10:07:20 AM PDT
*To: *Allen Tom mailto:a...@yahoo-inc.com>>
*Cc: *secur...@openid.net <mailto:secur...@openid.net>, 
gene...@openid.net <mailto:gene...@openid.net>

*Subject: **Re: [security] OpenID Security Best Practices Doc*
*Reply-To: *sappe...@gmail.com <mailto:sappe...@gmail.com>

On Tue, Jun 9, 2009 at 5:38 AM, Allen Tom <mailto:a...@yahoo-inc.com>> wrote:


Is the community ready to move forward with OpenID 2.1? 



I can't necessarily speak for the community, but I'd at least like to 
move forward with the 2.1 Discovery WG.  The output of that is 
expected to be a "best practices" document relating to Discovery that 
would (it is expected) be used in the regular OpenID 2.1 WG.


I'm not opposed to doing all of this in parallel.
 


I do believe that we really need a security best practices
document, and it shouldn't have to wait until OpenID 2.1 is
finalized.


+1
 



Anyway, when you said you had been "nominated", it made me
think there's some shadow process going on behind the scenes
when it comes to these Working Groups.

At the December 2008 IIW, I was either nominated or was
volunteered to work on Security Best Practices document after I
strongly advocated that the community write one.


Cool.  Like I said, I wasn't trying to say you shouldn't be doing 
this work.  I just wanted to make sure it was "open".  I wasn't at 
IIW, so that explains my disconnect.
 


Am I missing something?  Are there "private" WG discussions
going on that the rest of us can't see?

The security best practices document was first discussed at the
December 2008 IIW session on OpenID 2.1, completely in the open.


See my comment above.

 


Or are you just "taking some initiative", as it were?

Well, I'd been procrastinating for more than 6 months, but I
think we waited long enough. More and more sites want to deploy
OpenID, and it's about time we had a security document that
potential implementers can read, other than just reading the
specs, and various blog posts.


:)  -- I'm glad you've started working on this.  It's important to have.

 


-- I'm really just looking to get "in the loop" on this
Working Group business, assuming I'm out if currently).

I believe that the process requires the WG proposers to take
their proposal to the Specifications council who will review the
proposal and give their recommendation to the general membership
of the OIDF to either approve or deny the request to form the WG.
The general membership then votes on the proposal, and if the
proposal is approved, the WG is formed. There's also a very
painful process for the WG members to get their employers to
approve their participation in the WG.

The WG proposals that seem to be stalled right now appear to be
OpenID 2.1, SREG 1.1, and AX 2.0.


At least with regards to SREG 1.1 and AX 2.0, I believe that the
proposers are waiting for their employers to approve their
participation. Where is Dick Hardt? The OpenID world misses you!

I'm not sure about the status on OpenID 2.1, but at least for
myself, I'm more focused on the immediate goals of getting OpenID
OAuth Hybrid and the OpenID UI Extensions finalized.


I for one would like to move forward on the 2.1 Discovery WG.  XRD 
will be a big part of that, but at this point it seems like much of 
XRD has been solidified (at least, enough for us to

Re: Some suggestions about Open Id AX profile

[Allen Tom]

Hi David,

There has been a lot of discussion about adding Attribute Metadata to AX 
2.0, and this is within the charter of the proposed AX 2.0 Working Group.


http://wiki.openid.net/OpenID_Attribute_Exchange_Extension_2_0

One of the primary use cases driving this is to enable an OP to describe 
the user's email address. For instance, an email address returned via AX 
could just be a user-entered string that is totally unverified, or the 
email address could have been verified by the OP at some point in the 
past. A third option is that the OP is actually the user's email 
provider, and knows with 100% certainty that the user's email address is 
correct.


However, Trust is out of scope for AX 2.0. The RP would have to already 
trust the OP to make claims about the validity of the user's attributes.


The Contract Exchange WG is might be addressing your issue. I'm not 
quite sure what the status is on CX.

http://wiki.openid.net/Working_Groups%3AContract_Exchange_1

Allen


David Garcia wrote:
My company is starting a new Identity Management Service and we want 
to built it's AX interface over OpenId AX profile.


I'll introduce myself at the very beginning. My name is Dave Garcia 
and I'm working in a startup named Tractis in Spain. We have been 
offering online contracts using digital signatures for some years.  We 
want to allow users to use third OPs to login in our site and we want 
to become an OP too.


Also we want to offer identity services some of them using attribute 
exchange.  We are dealing with attributes being asserted by users and 
other are being certified by third parties (inside assertions, 
X509certificates...). We want to make a difference between attributes 
being asserted and those certified the same way authentication methods 
have different assurance levels PAPE profile.


Please let me paste here the briefing of what I'm talking about.

Disclaimer : the following document is in a very early stage, comments 
and suggestions are highly welcome.


Many thanks for everybody reading :)

Dave


  Short briefing for certified-AX profile for OpenId


  Abstract

Openid AX profile for openid provides a way to exchange attributes 
between relying parties and OP. Those attributes are simple key-value 
where the keys are commonly agreed identifiers and values are encoded 
strings. This approach works fine when dealing with "alegated 
attributes" like email, name ... but a problem arises when we need to 
trust this information ("certified attributes").


There are some services that works fine using alegated identities but 
some specially sensitive services, such as banking, don't. In these 
sensitive scenarios, we need to ensure the quality/trustworthiness of 
those attributes. Making a parallelism with existing open specs we 
need to apply mechanisms analogous to those defined on the PAPE for OP 
authentication but for attribute exchange.


From out point of view, and regarding to this existent needs, it would 
be nice to have those attributes scored using a commonly defined 
criteria so when OP returns a certain set of attributes relying party 
could trust them according to the score that OP gave them.



Motivations

Openid is moving towards being the de facto standard for 
authentication on the web. There are some other solutions to deal with 
attributes but it would be nice to have a single technology, empowered 
by the use of their plugins, to deal with identity.



Scenario

Here we'll expose an example of the messages exchanged during 
certificate attributes fetching.



Fetch


  Relying party

openid.ns.ax=http://openid.net/srv/ax/1.0 #To be redefined if a new 
release of the protocol is created


openid.ax.mode=fetch_request

openid.ax.type.age=http://axschema.org/birthDate

openid.ax.update_url=http://idconsumer.com/update?transaction_id=a6b5c41


  OpenidProvider

openid.ns.ax=http://openid.net/srv/ax/1.0 openid.ax.mode=fetch_response

openid.ax.type.age=http://axschema.org/birthDate

openid.ax.value.age=23

*openid.ax.score.age=3*

*openid.ax.receipt = #Some kind of receipt certifying the methods used 
to certify the attribute and that could be used for further processes*


openid.ax.update_url=http://idconsumer.com/update?transaction_id=a6b5c41


Store

In our approach OP deals with attribute certification processes : 
validating certificates, contacting with attribute certification 
authorities ... so there's no sense to allow the store of attributes 
from others than OP.


Store is applied only to non certified attributes, this is score 0.


What are scores

Scores works in the same way PAPE levels does. They measure the way 
attributes are certified and how the data being certified have been 
collected.


For example: attributes that have been gathered from a /qualified 
certificate/ (according to EU Directive on electronic Signatures) that 
is stored inside a SSCD the score will be 4 (means high). On the other 
hand, a name that has been aleg

Re: SREG's Privacy Policy URL

[Allen Tom]

The internationalization problem is one of the reasons why it might make 
more sense for the privacy policy url to be passed in as a parameter by 
the RP. The RP already is passing the user's language to the OP as part 
of the UI extension, so we could just make this an additional parameter.


Alternatively, we can just say that the RP has a single privacy policy 
url, and the Privacy Polocy URL can take an optional openid.ui.lang 
parameter. The privacy policy url can be discoverable.


Allen



Andrew Arnott wrote:
Would internationalizing entail the OP getting the URL for the RP's 
privacy policy in the right language?


If so, why not just have one URL and let the RP detect the user 
agent's preferred language? (Yes, I know the UI extension has this for 
the reason that the user agent isn't properly configured, so it's an 
interesting point...)

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the 
death your right to say it." - S. G. Tallentyre



On Tue, Jun 2, 2009 at 11:24 AM, Johannes Ernst <http://openid.net>@netmesh.us <http://netmesh.us>> wrote:


Is there a way this can be internationalized?


On Jun 2, 2009, at 11:14, Allen Tom wrote:

OK, how about if we define a new Privacy Policy  for
RPs to include in their XRDS, with a link to their privacy policy?

So the RP would just include the following snippet in its
discovery document, discoverable under its realm:


http://specs.openid.net/path/to/privacy/policy
http://www.relyingparty.com/path/to/privacy/policy.html


I'm not sure where we can formally document this. I guess we
can put it in the UI spec?

Allen



George Fletcher wrote:

I think for a short-term solution we'd need to define
service "types" for the privacy policy and TOS for XRDS.

For the long-term, the same could potentially be used as
"rel" values in the XRD markup. The XRD spec is
solidifying but is not 100% stable.

I think we should have a discovery option regardless of
whether we update UX or AX. So I'd like to see a proposal
for XRDS and then when XRD is available, supporting that.

Thanks,
George

Allen Tom wrote:

Hi Luke,

Yes, this is what we're looking for. Currently, in
OpenID, the only way for the RP to link to its privacy
policy (which is sort of like linking to its ToS) is
by passing it in the openid.sreg.policy_url parameter
using SREG.

Since we're trying to deprecate SREG, we can try to
move this parameter to either the UI or AX Extension,
or move it into Discovery.

Is there an actual Discovery spec?

Allen


Luke Shepard wrote:

FWIW, Facebook Connect allows relying parties to
define a “terms of service” url. We then show that
link to users when they click on it. With OpenID,
the equivalent URL would be set using relying
party discovery. Is this more or less what you’re
        looking for?

Screenshot:




On 6/2/09 10:21 AM, "Allen Tom"
mailto:a...@yahoo-inc.com>>
wrote:


  Alternatively, the RP could publish its privacy
policy in its
  discovery
  document, which does make a lot of sense, but I
understand that
  there's
  a lot of work going on to define the next
generation of
  discovery, and
  I'm not quite sure what the timeframe is for that.





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



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


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




___
specs mailing list
specs@openid.net
http://openid.net/ma

Re: SREG's Privacy Policy URL

[Allen Tom]

OK, how about if we define a new Privacy Policy  for RPs to 
include in their XRDS, with a link to their privacy policy?


So the RP would just include the following snippet in its discovery 
document, discoverable under its realm:



 http://specs.openid.net/path/to/privacy/policy
 http://www.relyingparty.com/path/to/privacy/policy.html


I'm not sure where we can formally document this. I guess we can put it 
in the UI spec?


Allen



George Fletcher wrote:
I think for a short-term solution we'd need to define service "types" 
for the privacy policy and TOS for XRDS.


For the long-term, the same could potentially be used as "rel" values 
in the XRD markup. The XRD spec is solidifying but is not 100% stable.


I think we should have a discovery option regardless of whether we 
update UX or AX. So I'd like to see a proposal for XRDS and then when 
XRD is available, supporting that.


Thanks,
George

Allen Tom wrote:

Hi Luke,

Yes, this is what we're looking for. Currently, in OpenID, the only 
way for the RP to link to its privacy policy (which is sort of like 
linking to its ToS) is by passing it in the openid.sreg.policy_url 
parameter using SREG.


Since we're trying to deprecate SREG, we can try to move this 
parameter to either the UI or AX Extension, or move it into Discovery.


Is there an actual Discovery spec?

Allen


Luke Shepard wrote:
FWIW, Facebook Connect allows relying parties to define a “terms of 
service” url. We then show that link to users when they click on it. 
With OpenID, the equivalent URL would be set using relying party 
discovery. Is this more or less what you’re looking for?


Screenshot:




On 6/2/09 10:21 AM, "Allen Tom"  wrote:


Alternatively, the RP could publish its privacy policy in its
discovery
document, which does make a lot of sense, but I understand that
there's
a lot of work going on to define the next generation of
discovery, and
I'm not quite sure what the timeframe is for that.





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




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

SREG's Privacy Policy URL

[Allen Tom]

Hi All,

The Simple Registration Extension provides an interface for the RP to 
pass the OP a link to the RP's privacy policy in the authentication 
request. According to the SREG spec, OPs SHOULD display this URL to the 
End User if it is given.


http://openid.net/specs/openid-simple-registration-extension-1_1-01.html#anchor3

Although Attribute Exchange is intended to be be a superset of SREG, the 
AX 1.0 spec omitted this feature. Some OPs (like Yahoo) believe that 
it's important to link to the RP's privacy policy, so it's unfortunate 
that this parameter was left out of AX. We think it's important that 
there's an automated way for an RP to inform the OP about its privacy 
policy without requiring the RP to pre-register itself with the OP.


Arguably, the RP's privacy policy is relevant even if there's no SREG/AX 
involved, so perhaps it doesn't make sense to require the RP to use 
SREG/AX to pass its privacy policy to the OP.


Given that the intent of the openid.sreg.policy_url parameter in SREG is 
to define an interface for the RP to ask the OP to link to the RP's 
privacy policy on the OP's UI,  it seems that this feature could be 
included in the OpenID User Interace Extension, which is intended to 
allow the RP to influence aspects of the OP's UI.


Alternatively, the RP could publish its privacy policy in its discovery 
document, which does make a lot of sense, but I understand that there's 
a lot of work going on to define the next generation of discovery, and 
I'm not quite sure what the timeframe is for that.


Comments?
Allen

.


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

Re: Does OAuth security vulnerability affect OpenID/OAuth hybrid?

[Allen Tom]

At the very least, the security considerations section should say that 
the OP should have obtained the user's consent to authorize the Access 
Token before issuing it to the RP. This means that the Access Token 
should not be returned via checkid_immediate unless the user had 
approved the token on a previous checkid_setup request.


There are federation scenarios (ie: close partnerships, etc) where user 
consent might not be necessary, so obtaining the user's consent is a 
SHOULD (or STRONGLY RECOMMENDED) rather than a MUST.


Allen


Breno de Medeiros wrote:

I can see some federation scenarios where admins might want to
configure auto-approvals for specific set of scopes for some set of
users (essentially OpenID as a single sign-on mechanism with data
transport). Putting this restriction directly into the standard as a
MUST or SHOULD would mean that libraries would likely enforce checks
(maybe without a configuration option) and make such deployments hard.

Maybe we should have a security considerations sections?

On Wed, May 13, 2009 at 5:05 PM, Andrew Arnott  wrote:
  

I would expect a decent OP to consider that it goes without saying that
checkid_immediate wouldn't have a reasonable OAuth token authorizing
scenario and block it.  So I agree it's good to call it out in the spec.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre


On Tue, May 12, 2009 at 10:06 PM, Allen Tom  wrote:


Hi Luke,

I don't think there's a session fixation issue with Hybrid, but I believe
that several individuals raised concerns regarding auto-approval of OAuth
tokens using regular OAuth, which is essentially the same thing as
checkid_immediate mode in Hybrid.

Is there really a reason why an RP would need the OAuth token returned in
a checkid_immediate response if the user had previously authorized one on an
earlier visit?

Allen


Luke Shepard wrote:

(hijacking thread a bit)

Allen-

If I understand it correctly, the OAuth security issue doesn’t affect the
hybrid spec in the same way.

With the OAuth session fixation vulnerability, the problem comes if the
attacker does the following:

Request a request token by pretending to request access
Force the user to go to a url using that request token
Muah! Calculate what the return_to url would have been, and use the
pre-known request token to gain access to the user’s account info.

In the OAuth hybrid flow, there is no pre-registered request token;
instead, the token is returned, securely, in the URL. It is protected by the
fact that OpenID requires the realm to match the return_to, and many
providers can require that the Oauth request realm also match the OpenID
realm. In this flow, there’s no way for the attacker to intercept the
request_token before it makes its way back to the correct user.

Perhaps the problem is more subtle than I understood, but I just want  to
make sure I’m clear on the issues.

On 5/12/09 9:48 PM, "Allen Tom"  wrote:

Hi Nat,

Here you go:


http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html

We might need to revise the spec to not support checkid_immediate for
the Hybrid flow, becuase auto-issuing OAuth access tokens is probably a
bad thing, in light of the recent OAuth security issue.

Allen





Nat Sakimura wrote:
  

Hi.

Where can I find the most current version of OpenID / OAuth hybrid spec
draft?
I would like to look at it to see if I can borrow as much from the
draft for what I am thinking right now.




___
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







  


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

Re: Requiring Pseudonymous Identifier

[Allen Tom]

I don't think it makes sense to use an AX attribute for the pseudonymous 
identifier, since assertion will still contain the correlatable OpenID 
identifier. It seems that the OP should return a unique RP-specific 
OpenID in the response.


Breno's idea about using an identifier-less request is interesting, but 
the RP is asking to sign the user in, so the request is about an identifier.


Allen

David Recordon wrote:
Does it make more sense to use a PAPE policy requesting a pseudonymous 
identifier or an AX attribute requesting one?  Any of these approaches 
would work, I just don't think we've mapped out the pros/cons of each.


--David

On May 13, 2009, at 8:44 AM, George Fletcher wrote:

I don't think OpenID should specify how pseudonymous identifiers are 
generated. That should be up to the OP. But I like the idea of using 
a fixed URI as the claimed_id value to specify the behavior desired 
by the RP. If, however, we need to grow this to cover anonymous based 
identifiers (i.e. the claims based models from earlier in this 
thread) then it might make sense to look at a PAPE extension that 
covers the type of identifier requested.


Thanks,
George

Nat Sakimura wrote:

Sorry for a slow response. This week is especially busy for me...

I borrowed the notion from Austrian Citizen ID system.
In there, the services are divided into "sectors."
A sector may span several agencies.
They call ID as PIN (Personal Identification Number).

There is a secret PIN (sPIN) which is not used anywhere but in their 
SmartCard.

Then, sector sepcific PIN (ssPIN) is calculated in the manner of :

SHA1(sPIN + SectorID)

(Note, there is a bit more details but...)

I have thrown OP secret into it.
To avoid the analytic attack, I agree that it is better to use
individual secret, as some of you
points out.

Regards,

=nat

On Tue, May 12, 2009 at 5:55 PM, Dick Hardt  
wrote:



On 12-May-09, at 1:36 AM, Nat Sakimura wrote:


Reason for using RP's Subject in XRD instead of simply using realm is
to allow for something like group identifier.


would you elaborate on the group identifier concept?



This is just one idea. Downside of this approach
is that we need to set up a WG.

I am sure there are more ideas. It might be possible to utilize AX
so that it will only be a profile that does not require a WG.

So shall we start discussing which direction we want to go forward?


sure!








___
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: Identifier for group of individulas

[Allen Tom]

The intent of the fragment was to allow OPs to recycle OpenIDs, and the 
fragment is intended to be a "generation identifier" that RPs can use to 
determine that the OpenID was recycled.


Allen


Andrew Arnott wrote:
From the spec 
:



  11.5.1.  Identifier Recycling

OpenID Providers with large user bases can use fragments to recycle 
URL Identifiers if it is so desired. When * reassigning *a URL 
Identifier to a */new /end user *OPs should generate a new, unique 
fragment part.


The full URL with the fragment part constitutes the Claimed Identifier 
in positive assertions, therefore Relying Parties will distinguish 
between *the current and /previous /owners *of the fragment-less URL.


This mechanism allows the (presumably short, memorable) recycled URL 
Identifiers without the fragment to be used by end users at login time 
and by Relying Parties for display purposes.


This smells hugely of the idea that only one user controls an 
identifier at a time.


--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the 
death your right to say it." - Voltaire



On Wed, May 13, 2009 at 10:27 AM, Nat Sakimura > wrote:


My interpretation is that the fragment does not necessarily mean a new
user, but it just differentiate among different users.

=nat

On Thu, May 14, 2009 at 2:15 AM, Andrew Arnott
mailto:andrewarn...@gmail.com>> wrote:
> Fragments are valid URI parts.  But they are unique in that a
web browser
> never sends them to the server.  The OpenID 2.0 spec
specifically calls out
> fragments as valid ways that OPs can indicate to RPs that a new user
> controls this identifier.
>
> So in fact that may be a problem.  Multiple users could be
asserting control
> of the identifier (minus the fragment).  The OpenID 2.0 spec at
least hints
> that OPs will use this generational #fragment to indicate a new user
> controls the identifier (identifier recycling).  An RP that sees
a new
> fragment attached to a claimed_id may assume (perhaps rightly)
that the old
> user is now gone and delete settings for the old user.  If the
OP habitually
> sticks on random goo to the end of an identifier via its
#fragment, then
> that interpretation by the RP would not be safe.
>
> I don't know if others read the spec that way though.
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to
the death
> your right to say it." - Voltaire
>
>
> On Wed, May 13, 2009 at 10:08 AM, Santosh Rajan
mailto:santra...@gmail.com>> wrote:
>>
>> I am not sure about fragments. I dont think the fragment falls
under the
>> deifinition of URI. see rfc 3986.
>> The group can be indentified within the path part, assuming all
members of
>> the group belong to the same OP and the group is known while
issuing the
>> OpenID. In that case we dont need anything to define at the
OpenID level.
>> Or am i missing something here?
>>
>> Andrew Arnott wrote:
>> >
>> > Appending a fragment at least will help the RP distinguish
between
>> > identifiers. And in the short term it has the merit of not
requiring any
>> > spec changes.
>> >
>> > But I still would like to see a group membership claim kept
separate
>> > from
>> > the identity claim, perhaps via the claim discovery I
described in the
>> > other
>> > thread.
>> > --
>> > Andrew Arnott
>> > "I [may] not agree with what you have to say, but I'll defend
to the
>> > death
>> > your right to say it." - Voltaire
>> >
>> >
>> > On Wed, May 13, 2009 at 9:31 AM, Nat Sakimura
mailto:sakim...@gmail.com>>
>> > wrote:
>> >
>> >> My previous post on pseudonymous identifier seemed to have
kicked off
>> >> interesting but orthogonal discussion of identifier for group of
>> >> individuals (like school class, friends, etc.)
>> >>
>> >> Please use this thread instead for this discussion.
>> >>
>> >> Just to put an context to the discussion, I can put one deployed
>> >> example of this type of identifier use.
>> >>
>> >> mixi, the largest Japanese SNS, is using the concept of "group
>> >> identifier."
>> >>
>> >> For example, to prove you are a friend of mine, you can
authenticate
>> >> with the identifier
>> >>
>> >> https://id.mixi.jp/nat/friend
>> >>
>> >> The verified identifier would be something like
>> >> https://id.mixi.jp/nat/friend#hashOfYourId etc.,
>> >> if I rememer right.
>> >>
>> >> As you can see, it requires no change in the OpenID AuthN
2.0 nor an
>> >> extension.
>> >>
>> >> Anyways.. my 2c.
>> >>
>> >> =nat
>> >>
>> >> --

Re: Does OAuth security vulnerability affect OpenID/OAuth hybrid?

[Allen Tom]

I like the idea of issuing a short lived Access Token that has to be 
periodically refreshed using checkid_immdiate , implying  that the user 
needs to be signed-in to  both the OP (and presumably the RP) in order 
to refresh the credentials. This makes a lot of sense from a security 
perspective, and helps to mitigate the scenario where an RP that the 
user doesn't actively use has persistent access to user's data.


However, I believe that the conventional use case for OAuth is to issue 
persistent credentials to the RP to allow the RP to access services on 
behalf of the user, independent of the user having an active browser 
session at either the OP or RP.


Allen


Luke Shepard wrote:

As I suggested, an OP may want to give an updated session via 
checkid-immediate. Facebook Connect does this, and it seems like a legit use 
case to me.


From: Andrew Arnott 
To: Allen Tom 
Cc: Luke Shepard; OpenID Specs Mailing List 
Sent: Wed May 13 17:05:00 2009
Subject: Re: Does OAuth security vulnerability affect OpenID/OAuth hybrid?

I would expect a decent OP to consider that it goes without saying that 
checkid_immediate wouldn't have a reasonable OAuth token authorizing scenario 
and block it.  So I agree it's good to call it out in the spec.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your 
right to say it." - S. G. Tallentyre


On Tue, May 12, 2009 at 10:06 PM, Allen Tom 
mailto:a...@yahoo-inc.com>> wrote:
Hi Luke,

I don't think there's a session fixation issue with Hybrid, but I believe that 
several individuals raised concerns regarding auto-approval of OAuth tokens 
using regular OAuth, which is essentially the same thing as checkid_immediate 
mode in Hybrid.

Is there really a reason why an RP would need the OAuth token returned in a 
checkid_immediate response if the user had previously authorized one on an 
earlier visit?

Allen


Luke Shepard wrote:
(hijacking thread a bit)

Allen-

If I understand it correctly, the OAuth security issue doesn’t affect the 
hybrid spec in the same way.

With the OAuth session fixation vulnerability, the problem comes if the 
attacker does the following:


 1.  Request a request token by pretending to request access
 2.  Force the user to go to a url using that request token
 3.  Muah! Calculate what the return_to url would have been, and use the 
pre-known request token to gain access to the user’s account info.

In the OAuth hybrid flow, there is no pre-registered request token; instead, 
the token is returned, securely, in the URL. It is protected by the fact that 
OpenID requires the realm to match the return_to, and many providers can 
require that the Oauth request realm also match the OpenID realm. In this flow, 
there’s no way for the attacker to intercept the request_token before it makes 
its way back to the correct user.

Perhaps the problem is more subtle than I understood, but I just want  to make 
sure I’m clear on the issues.

On 5/12/09 9:48 PM, "Allen Tom" http://a...@yahoo-inc.com>> 
wrote:

Hi Nat,

Here you go:

http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html

We might need to revise the spec to not support checkid_immediate for
the Hybrid flow, becuase auto-issuing OAuth access tokens is probably a
bad thing, in light of the recent OAuth security issue.

Allen





Nat Sakimura wrote:
  

Hi.

Where can I find the most current version of OpenID / OAuth hybrid spec draft?
I would like to look at it to see if I can borrow as much from the
draft for what I am thinking right now.





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



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


  


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

Re: Does OAuth security vulnerability affect OpenID/OAuth hybrid?

[Allen Tom]

Hi Luke,

I don't think there's a session fixation issue with Hybrid, but I 
believe that several individuals raised concerns regarding auto-approval 
of OAuth tokens using regular OAuth, which is essentially the same thing 
as checkid_immediate mode in Hybrid.


Is there really a reason why an RP would need the OAuth token returned 
in a checkid_immediate response if the user had previously authorized 
one on an earlier visit?


Allen


Luke Shepard wrote:

(hijacking thread a bit)

Allen-

If I understand it correctly, the OAuth security issue doesn't affect 
the hybrid spec in the same way.


With the OAuth session fixation vulnerability, the problem comes if 
the attacker does the following:


   1. Request a request token by pretending to request access
   2. Force the user to go to a url using that request token
   3. Muah! Calculate what the return_to url would have been, and use
  the pre-known request token to gain access to the user's account
  info.


In the OAuth hybrid flow, there is no pre-registered request token; 
instead, the token is returned, securely, in the URL. It is protected 
by the fact that OpenID requires the realm to match the return_to, and 
many providers can require that the Oauth request realm also match the 
OpenID realm. In this flow, there's no way for the attacker to 
intercept the request_token before it makes its way back to the 
correct user.


Perhaps the problem is more subtle than I understood, but I just want 
 to make sure I'm clear on the issues.


On 5/12/09 9:48 PM, "Allen Tom"  wrote:

Hi Nat,

Here you go:


http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html

We might need to revise the spec to not support checkid_immediate for
the Hybrid flow, becuase auto-issuing OAuth access tokens is
probably a
bad thing, in light of the recent OAuth security issue.

Allen





Nat Sakimura wrote:
> Hi.
>
> Where can I find the most current version of OpenID / OAuth
hybrid spec draft?
> I would like to look at it to see if I can borrow as much from the
> draft for what I am thinking right now.
>
>  


___
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: Most current version of OpenID / OAuth hybrid spec draft?

[Allen Tom]

Hi Nat,

Here you go:

http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html

We might need to revise the spec to not support checkid_immediate for 
the Hybrid flow, becuase auto-issuing OAuth access tokens is probably a 
bad thing, in light of the recent OAuth security issue.


Allen





Nat Sakimura wrote:

Hi.

Where can I find the most current version of OpenID / OAuth hybrid spec draft?
I would like to look at it to see if I can borrow as much from the
draft for what I am thinking right now.

  


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

Re: Defining how OpenID should behave with fragments in the return_to url

[Allen Tom]

Oops, I missed the followups to this thread. We updated our OAuth 
service this week to change the behavior for fragments in the 
oauth_callback URL so that we always return query parameters *before* 
the fragment.


oauth_callback=http://example.com/callback?foo=bar#fragment

Old Behavior:
   http://example.com/callback?foo=bar#fragment&oauth_token=token

New Behavior:
   http://example.com/callback?foo=bar&oauth_token=token#fragment

It sounds like the Old Behavior is what Luke is asking for. It works 
well if the parameters are parsed in JS, without any server side help, 
but appending parameters after the fragment prevents the params from 
being sent to the server (which is the point, if you're trying to avoid 
caching, but is broken if you actually want the process the params on 
the server)


For the time being, we'll just keep the current behavior on the Yahoo OP.

Given that this fragment technique is intended to improve the user 
experience, especially in the context of a popup window, I think that we 
may be able to document the correct behavior this in the forthcoming UI 
Extension.


Allen




Dirk Balfanz wrote:
Wait - isn't Luke saying that Yahoo! is currently supporting this just 
fine? What are you "fixing"?


Dirk.

On Tue, Mar 24, 2009 at 2:16 PM, Allen Tom <mailto:a...@yahoo-inc.com>> wrote:


Hi Luke,

I have to confess that I was not aware of technique of passing
parameters after the fragment to take advantage of browser
caching, until you blogged about it. Since then, we've noticed
that developers have been doing this, and in fact, we fixed the
same bug on our OAuth service just last week.

We will update our OP to support return_to URLs with a fragment.
I'll let you know when it's fixed.

Thanks
Allen



Luke Shepard wrote:

Hi-

I’ve noticed an ambiguity with the way URLs are handled that
exists in the current spec. I’m hoping we can resolve it for
OpenID 2.1.

When we move the OpenID transaction into a popup window, we need
a way for the popup to communicate back with the parent. The way
to do this is to set a return_to URL that, when loaded, reads the
parameters and communicates with the parent window somehow.

Here’s a description of a technique:

http://www.sociallipstick.com/2009/02/04/how-to-accept-openid-in-a-popup-without-leaving-the-page/

A simple way to do this is to have a simple receiver. The
response will append query parameters:

http://open.lukeshepard.com/openid_receiver.php?openid.ns=..

However, there is a small performance problem with this approach.
The user will see a blank-looking popup for a moment while the
server processes the OpenID arguments. An optimization is to put
up a simple, cacheable static HTML file that chucks the OpenID
params back to the parent frame. The parent can then provide some
visual feedback to the user while it sends the OpenID parameters
off for processing. This results in a snappier experience.

If the static HTML file has no parameters and sends out
long-lived cache headers, then the response won’t even trigger a
server load, and the whole process can appear faster to the user.
In this case, the response would look like this:

http://open.lukeshepard.com/openid_receiver.html#openid.ns=..

Note that the hash appears instead of a question-mark. That tells
the browser that it doesn’t need to load an extra file, and it
can save perhaps a quarter or half second of latency for the user
on average.

Okay, so the point is that different OpenID providers currently
interpret the hash differently. I think we should explicitly
define a behavior that makes sense and accomodates the above
suggestion. Here’s how they currently behave.

When given a return_to of
http://open.lukeshepard.com/openid_receiver.html?query#hash

Google:
http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns=
Yahoo:
http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns=
MySpaceID:
http://open.lukeshepard.com/openid_receiver.html?query&openid.ns=#hash
<http://open.lukeshepard.com/openid_receiver.html?query&openid.ns=#hash>
MyOpenID: fails outright - “invalid return_to”

By the URL spec, Myspace is technically correct and Google/Yahoo
are wrong. But the “correct” way doesn’t allow the performance
optimization listed above. I’d like to see a way to accommodate
the hash url.

One crude way to do it would be to have the caller specify that
they want the return_to args simply appended instead of
integrated into the URL- perhaps an argument like
openid.append_return_to_params=true. But that sounds hackish and
I’d love to hear feedback on a better way to do this.

Also, let

Re: Defining how OpenID should behave with fragments in the return_to url

[Allen Tom]

Hi Luke,

I have to confess that I was not aware of technique of passing 
parameters after the fragment to take advantage of browser caching, 
until you blogged about it. Since then, we've noticed that developers 
have been doing this, and in fact, we fixed the same bug on our OAuth 
service just last week.


We will update our OP to support return_to URLs with a fragment. I'll 
let you know when it's fixed.


Thanks
Allen



Luke Shepard wrote:

Hi-

I've noticed an ambiguity with the way URLs are handled that exists in 
the current spec. I'm hoping we can resolve it for OpenID 2.1.


When we move the OpenID transaction into a popup window, we need a way 
for the popup to communicate back with the parent. The way to do this 
is to set a return_to URL that, when loaded, reads the parameters and 
communicates with the parent window somehow.


Here's a description of a technique:
http://www.sociallipstick.com/2009/02/04/how-to-accept-openid-in-a-popup-without-leaving-the-page/

A simple way to do this is to have a simple receiver. The response 
will append query parameters:


http://open.lukeshepard.com/openid_receiver.php?openid.ns=..

However, there is a small performance problem with this approach. The 
user will see a blank-looking popup for a moment while the server 
processes the OpenID arguments. An optimization is to put up a simple, 
cacheable static HTML file that chucks the OpenID params back to the 
parent frame. The parent can then provide some visual feedback to the 
user while it sends the OpenID parameters off for processing. This 
results in a snappier experience.


If the static HTML file has no parameters and sends out long-lived 
cache headers, then the response won't even trigger a server load, and 
the whole process can appear faster to the user. In this case, the 
response would look like this:


http://open.lukeshepard.com/openid_receiver.html#openid.ns=..

Note that the hash appears instead of a question-mark. That tells the 
browser that it doesn't need to load an extra file, and it can save 
perhaps a quarter or half second of latency for the user on average.


Okay, so the point is that different OpenID providers currently 
interpret the hash differently. I think we should explicitly define a 
behavior that makes sense and accomodates the above suggestion. Here's 
how they currently behave.


When given a return_to of 
http://open.lukeshepard.com/openid_receiver.html?query#hash


Google: 
http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns=
Yahoo: 
http://open.lukeshepard.com/openid_receiver.html?query#hash?openid.ns=
MySpaceID: 
http://open.lukeshepard.com/openid_receiver.html?query&openid.ns=#hash 


MyOpenID: fails outright - "invalid return_to"

By the URL spec, Myspace is technically correct and Google/Yahoo are 
wrong. But the "correct" way doesn't allow the performance 
optimization listed above. I'd like to see a way to accommodate the 
hash url.


One crude way to do it would be to have the caller specify that they 
want the return_to args simply appended instead of integrated into the 
URL- perhaps an argument like openid.append_return_to_params=true. But 
that sounds hackish and I'd love to hear feedback on a better way to 
do this.


Also, let me know if this is the wrong list or whatever.

thanks,
- Luke


___
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 to consider creation of the User Interface Work Group

[Allen Tom]

+1!

Improving OpenID UX and adding support for internationalization should 
definitely be done ASAP. The scope is focused and well defined, and I'm 
confident that we will be able to quickly write a very short spec that 
will greatly improve OpenID's usability and demonstrate our commitment 
to deploy OpenID worldwide.


(I might be a bit biased)
Allen

Allen Tom wrote:

Hi Specs Council,

Please consider the attached proposal to form the User Interface Work 
Group.

http://wiki.openid.net/OpenID-User-Interface-Work-Group-Proposal


   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 (still liable to change during this 
feedback period).


 Name

OpenID User Interface Working Group


 Background Information

OpenID traditionally requires the Relying Party to redirect the entire 
browser window to the OpenID Provider for the user to authenticate 
before redirecting the browser back to the Relying Party. It is 
believed that the User Experience (UX) could be significantly improved 
if the authentication flow occurred within a smaller popup window, 
making the experience less disruptive to the user.
Although it is possible for Relying Parties to open a popup window for 
the user to authenticate at the OpenID Provider using the Provider's 
default user interface, the overall user experience can be optimized 
if the OP was aware that its UI was running within a popup. For 
instance, an OP may want to resize the popup browser window when using 
the popup interface, but would probably not want to resize the full 
browser window when using the default redirect interface. Another 
optimization is that the OP can close the popup, rather than return a 
negative assertion if the user chooses to cancel the authentication 
request.
Users who begin the OpenID sign in process on a Relying Party in one 
language and then transition to their OpenID Provider's site in a 
different language may find the overall experience to be very 
disruptive. In many cases, the Relying Party may want to pass a 
language hint to the OpenID Provider to use to display the User 
Interface to the user, especially if the user is not already 
authenticated at the OP.





 Statement of Purpose

This workgroup intends to produce a very brief OpenID extension to 
enable the OpenID Authentication User Interface to be invoked in a 
standalone popup window, and to allow the Relying Party to request 
that the user interface be displayed in a particular language.





 Scope

Produce an extension that allows an OpenID Provider to indicate its 
support of a popup friendly user interface, as opposed to the default 
user interface optimized for a full browser window. The popup must be 
in an independent browser window, and must not be framed by the RP.



The extension will also define a mechanim for RPs to pass a language 
hint to the OP to help determine the langange used to display the 
OpenID Authentication user interface.





 Out of Scope
The content of the user interface other than the language that the 
interface is displayed in is out of scope.





 Specifications
OpenID User Interface Extension 1.0

 Anticipated audience

All those interested in improving OpenID Usability.

 Language of business

English.

 Method of work

Mailing list discussion. Posting of intermediate drafts in the OpenID 
Wiki. Virtual conferencing on an ad-hoc basis.


 Basis for completion of the activity

The OpenID User Interface Extension 1.0 final draft is completed.

 Proposers

   * Allen Tom, a...@yahoo-inc.com, Yahoo!
   * Brian Ellin, br...@janrain.com, Janrain
   * David Recordon, da...@sixapart.com, Six Apart
   * Chris Messina, ch...@citizenagency.com, Vidoop/DiSo Project* 
Breno de Medeiros, br...@google.com, Google

   * Luke Shepard, lshep...@facebook.com, Facebook


 Initial Editors

   * Allen Tom, a...@yahoo-inc.com, Yahoo!
   * Breno de Medeiros, br...@google.com, Google


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


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

Request to consider creation of the User Interface Work Group

[Allen Tom]

Hi Specs Council,

Please consider the attached proposal to form the User Interface Work Group.
http://wiki.openid.net/OpenID-User-Interface-Work-Group-Proposal


   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 (still liable to change during this feedback 
period). 



 Name

OpenID User Interface Working Group


 Background Information

OpenID traditionally requires the Relying Party to redirect the entire 
browser window to the OpenID Provider for the user to authenticate 
before redirecting the browser back to the Relying Party. It is believed 
that the User Experience (UX) could be significantly improved if the 
authentication flow occurred within a smaller popup window, making the 
experience less disruptive to the user. 

Although it is possible for Relying Parties to open a popup window for 
the user to authenticate at the OpenID Provider using the Provider's 
default user interface, the overall user experience can be optimized if 
the OP was aware that its UI was running within a popup. For instance, 
an OP may want to resize the popup browser window when using the popup 
interface, but would probably not want to resize the full browser window 
when using the default redirect interface. Another optimization is that 
the OP can close the popup, rather than return a negative assertion if 
the user chooses to cancel the authentication request. 

Users who begin the OpenID sign in process on a Relying Party in one 
language and then transition to their OpenID Provider's site in a 
different language may find the overall experience to be very 
disruptive. In many cases, the Relying Party may want to pass a language 
hint to the OpenID Provider to use to display the User Interface to the 
user, especially if the user is not already authenticated at the OP.





 Statement of Purpose

This workgroup intends to produce a very brief OpenID extension to 
enable the OpenID Authentication User Interface to be invoked in a 
standalone popup window, and to allow the Relying Party to request that 
the user interface be displayed in a particular language.





 Scope

Produce an extension that allows an OpenID Provider to indicate its 
support of a popup friendly user interface, as opposed to the default 
user interface optimized for a full browser window. The popup must be in 
an independent browser window, and must not be framed by the RP. 




The extension will also define a mechanim for RPs to pass a language 
hint to the OP to help determine the langange used to display the OpenID 
Authentication user interface.





 Out of Scope 

The content of the user interface other than the language that the 
interface is displayed in is out of scope.





 Specifications 

OpenID User Interface Extension 1.0 



 Anticipated audience

All those interested in improving OpenID Usability. 



 Language of business

English. 



 Method of work

Mailing list discussion. Posting of intermediate drafts in the OpenID 
Wiki. Virtual conferencing on an ad-hoc basis. 



 Basis for completion of the activity

The OpenID User Interface Extension 1.0 final draft is completed. 



 Proposers

   * Allen Tom, a...@yahoo-inc.com, Yahoo!
   * Brian Ellin, br...@janrain.com, Janrain
   * David Recordon, da...@sixapart.com, Six Apart
   * Chris Messina, ch...@citizenagency.com, Vidoop/DiSo Project 
   * Breno de Medeiros, br...@google.com, Google

   * Luke Shepard, lshep...@facebook.com, Facebook


 Initial Editors

   * Allen Tom, a...@yahoo-inc.com, Yahoo!
   * Breno de Medeiros, br...@google.com, Google


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

Re: Suggested scoping for AX 2.0 WG

[Allen Tom]

Hi Dick,

I'll be happy to add language to the revised SREG spec to strongly 
encourage all new deployments to use AX and to NOT  use SREG, however, 
given the current popularity of SREG, I think it's a good idea to 
clarify and modernize it a bit. Speaking on behalf of Yahoo, once we 
have a usable version of AX, we will encourage RPs to use AX over SREG.


I do agree that AX for multiple users in a single request is quite a bit 
different than the current design pattern, where an assertion is about a 
single user. I'm not sure how bulk AX would work without OAuth.


Allen

Dick Hardt wrote:

1) I'd prefer to NOT include SREG in the work, but am ok with it being in if 
the scope is really to clarify issues in SREG and add language directing people 
to AX. Anyone else have a strong opinion either way? (SREG included in this WG 
or in a different one?)

2) In the Scope section, I feel strongly that bulk exchange of attributes about 
multiple users is out of scope. It is a very different design pattern then what 
AX does now. I have not seen the background on why this is in scope, so perhaps 
I can have a different view if someone cares to enlighten me.

-- Dick

PS: please use my microsoft.com address for any specs discussions.

  


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

Re: OpenID Mobile Profile?

[Allen Tom]

Hi Nat,

OpenID has a huge opportunity in the mobile market, because logging 
in/registering is at least an order of magnitude more painful on a 
handset than on a standard desktop browser. Even with my iPhone, logging 
in is terrible, and I can't think of a single time I've bothered to 
register.


At least from my perspective, I'm more interested in discussing UX 
rather than protocol changes. Although the URLs are getting really long, 
the URL length is an implementation detail that is mostly hidden from 
the user. Supporting the equivalent of SAML's artifact binding as an 
additional OpenID communication mode isn't really going to improve the 
UX for users of iPhone class devices.


Because OpenID and OAuth appear to be converging, I'd prefer to see 
artifact-type binding implemented using OAuth's Request Token. In OAuth, 
the RP (aka Consumer) first requests a Request Token using direct 
communication, and then redirects the browser to the OP (aka SP) with 
the Request Token to maintain the state. Instead of having the browser 
pass all the request parameters on the URL, all the parameters are 
represented by the Request Token, which is intented to be relatively short.


Allen


Nat Sakimura wrote:

Hi.

Are there poeple who are interested in discussing OpenID Mobile 
profile sort of thing?
Mobile phones has unique challenges of being restricted in URL length 
etc.
OpenID as it stands now has very lengthy URLs in both requests and 
responses and it sometimes does not fit into the restrictions.
SAML world has defined artifact binding to cope with it. IMHO, OpenID 
should define something like that also.


In Japan, there are bunch of people (including mobile carriers) who 
wants to do it.


Are there interest here as well?

--
Nat Sakimura (=nat)
http://www.sakimura.org/en/


___
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

[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

[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

[Allen Tom]

Can we extend the scope to include patching SReg to include avatar 
image, and also details about the quality of the user's email address?


AX also needs to be updated to allow RPs to pass the url of their 
privacy policy to the OP, this is equivalent to SReg's 
openid.sreg.policy_url.


Because SReg does seem to be a bit more widely used, perhaps SReg can be 
positioned as a lightweight version of AX.


Allen

David Recordon wrote:
This has been on my list to kick to the specs council but I've also 
been waiting for Dick to reengage since he's been such a core driver 
of the AX spec in the past. :)


--David

- "Nat Sakimura"  wrote:
>
>
>
> On Sat, Jan 24, 2009 at 4:02 AM, Breno de Medeiros <mailto:br...@google.com>> wrote:

>

Unfortunately, not much to report except that most appear to agree in
> your last suggestion, which I parse as:
>
>   Allow type. = type_schema_url to define a 'type namespace'.
> Within that namespace it would then be possible to create an
> extensible schema based on plain string key-value pairs.
>
> We need to:
>
> 1. Get the blessing of specs council to form a WG. I believe we have
> addressed all concerns raised in threads in the Wiki proposal
and I am
> not sure why I have not heard from specs council back. How do we
call
> for a vote on the WG formation?


> Right. I will kick the specs council for this one also.
> The board is aware that specs council has not been effective and
> starting to fix it. (There will be a board voting to start the 
ammendment

> to the OpenID process shortly.)
>
> Guys, please raise your voices also from the community side.
>
> Dick, I think you still are a spec council member, so please start
> pinging other specs council members from inside.
>
> Process-wise, there are four more steps involved in startgin this WG.
>
> 1) Specs council's recommendation
> 2) Membership vote to form WG.
> 3) Contributors submitting IPR agreements for this WG.
> 4) OIDF to provide the post restricted ML and SVN repository for the 
WG.

>
> Additionally, it would be good if OIDF could supply "write controlled"
> wiki just like OASIS Open does.
>
>
>


>
> 2. Start writing this spec, in particular hash out the parts
that are
> in agreement so that people can start cranking on this. :)


> Yes!
>  
>



>
>
>
>
> On Fri, Jan 23, 2009 at 10:54 AM, Dick Hardt
mailto:dick.ha...@gmail.com>> wrote:
> > Hey Everyone
> > I dropped off the planet for a bit moving and getting my world
setup. Have
> > missed all the email threads on this.
> > What have I missed out on? :-)
> > I plan on participating heavy in the AX 2.0 spec myself.
> > -- Dick
> >
> > On Tue, Dec 23, 2008 at 12:12 PM, Allen Tom
mailto:a...@yahoo-inc.com>> wrote:
> >>
> >> I believe that one of the goals of AX 2.0 should be to maintain
> >> backwards compatible with AX 1.0 whenever possible.
> >>
> >> Allen
> >>
> >>
> >> Mike Jones wrote:
> >> > Can you add a clear statement to the draft charter that
implementations
> >> > already using AX 1.0 will remain compatible with the output
of this working
> >> > group?  Or is backwards-compatibility with existing AX
implementations not a
> >> > goal of this work?
> >> >
> >> > -- Mike
> >> >
> >> > -Original Message-
> >> > From: specs-boun...@openid.net
<mailto:specs-boun...@openid.net> [mailto:specs-boun...@openid.net
<mailto:specs-boun...@openid.net>] On
> >> > Behalf Of Breno de Medeiros
> >> > Sent: Thursday, December 18, 2008 6:18 PM
> >> > To: OpenID Specs Mailing List
> >> > Cc: d...@skip.com <mailto:d...@skip.com>;
hd...@ic-tact.co.jp <mailto:hd...@ic-tact.co.jp>;
mgra...@janrain.com <mailto:mgra...@janrain.com>
> >> > Subject: Request for consideration of Working Group Charter
Proposal
> >> >
> >> > I would like to submit the following proposal for a new
Working Group
> >> > charter to your consideration, following the OpenID IPR
process:
> >> >
> >> > The proposal charter is also available at:
> >> > http://wiki.openid.net/Working_Groups:AX_2.0
> >> >
> >> > Open

Re: CX proposal update

[Allen Tom]

Hi Nat,

How will the WG define workflow and proof of user consent if the charter 
says that UI and UX are out of scope?


Allen


Nat wrote:
Whether it really is legally binding depends on what jurisdiction you 
are in, but typically there are some minimal set of info that has to 
be included to be considered to be a good one. Namely, sufficiently 
unique identifiers for all the parties involved, term, date, expiry, 
renewal privision, termination clause, jurisdiction, and signatures. 
Signature sometimes is of not the subject but of a proxy agent. 
CX is going to define how these should be represented. 

These "contracts" typically lives long, and there are readability 
requirement as well. (I.e. it should not require a special software to 
read and understand what it means.) Cryptographically, it requires 
provisioning against algorithm getting compromised such as time stamping. 

We also have to define the verification procedure for all the above.  

Then, there is an issue of what entails the reasonable action and 
workflow etc. as a proof of user consent.   

So, in summary, while we intend to use AX (and/or OAuth hybrid) as the 
undelying protocol, it is a little more than merely defining another 
set of attributes.   


=...@tokyo via iPhone

On 2009/01/23, at 5:43, Allen Tom <mailto:a...@yahoo-inc.com>> wrote:



Hi Nat,

Can you define the term "contract"? Is it legally binding? It is just 
a signed set of attributes? Who are the parties involved with signing 
the contract? The RP, OP, and user? Instead of defining a new CX 
extension, would it just be sufficient to define new attributes using AX?


Would it make more sense to use OAuth instead of defining a new 
OpenID extension? OAuth is designed to allow a user to authorize an 
RP (aka Consumer) to access protected resources hosted by the user's 
OP (aka Service Provider). It might make more sense to use the 
OpenID+OAuth hybrid protocol along with an OAuth protected web 
service to exchange contract information.


Thanks
Allen




Nat Sakimura wrote:

I have edited the Contract Exchange Proposal on the wiki.

http://wiki.openid.net/Working_Groups%3AContract_Exchange_1

It is substantially shorter and easier to parse, hopefully.

Please discuss.

--
Nat Sakimura (=nat)
http://www.sakimura.org/en/


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




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

Re: CX proposal update

[Allen Tom]

Hi Nat,

Can you define the term "contract"? Is it legally binding? It is just a 
signed set of attributes? Who are the parties involved with signing the 
contract? The RP, OP, and user? Instead of defining a new CX extension, 
would it just be sufficient to define new attributes using AX?


Would it make more sense to use OAuth instead of defining a new OpenID 
extension? OAuth is designed to allow a user to authorize an RP (aka 
Consumer) to access protected resources hosted by the user's OP (aka 
Service Provider). It might make more sense to use the OpenID+OAuth 
hybrid protocol along with an OAuth protected web service to exchange 
contract information.


Thanks
Allen




Nat Sakimura wrote:

I have edited the Contract Exchange Proposal on the wiki.

http://wiki.openid.net/Working_Groups%3AContract_Exchange_1

It is substantially shorter and easier to parse, hopefully.

Please discuss.

--
Nat Sakimura (=nat)
http://www.sakimura.org/en/


___
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

[Allen Tom]

I believe that one of the goals of AX 2.0 should be to maintain 
backwards compatible with AX 1.0 whenever possible.

Allen


Mike Jones wrote:
> Can you add a clear statement to the draft charter that implementations 
> already using AX 1.0 will remain compatible with the output of this working 
> group?  Or is backwards-compatibility with existing AX implementations not a 
> goal of this work?
>
> -- Mike
>
> -Original Message-
> From: specs-boun...@openid.net [mailto:specs-boun...@openid.net] On Behalf Of 
> Breno de Medeiros
> Sent: Thursday, December 18, 2008 6:18 PM
> To: OpenID Specs Mailing List
> Cc: d...@skip.com; hd...@ic-tact.co.jp; mgra...@janrain.com
> Subject: Request for consideration of Working Group Charter Proposal
>
> I would like to submit the following proposal for a new Working Group
> charter to your consideration, following the OpenID IPR process:
>
> The proposal charter is also available at:
> http://wiki.openid.net/Working_Groups:AX_2.0
>
> OpenID Attribute Exchange 2.0 Working Group (AX 2.0)
>
>
> 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 (still liable to change during this
> feedback period).
>
>
> I. Name
>
> Attribute Exchange Extension Working Group (AX)
>
>
> II. Statement of Purpose
>
> Produce an updated version of the Attribute Exchange Extension.
>
>
> III. Scope
>
> Update the Attribute Exchange Extension to include support for
> identified needs. Currently identified needs:
>
> * Provide mechanisms for RP to require, and the OP to assert,
> claims about the quality of the attributes.
> * Create an extensible registry of claim types, such as
> axschema.org for attribute types. The registry should also provide
> non-normative guidance on how claims can be validated, which will
> depend on the nature of attribute type as well as claim type.
> * Introduce a new request/response mode which, unlike fetch and
> store, allows for both transmittal of some values and request of
> others. The transmittal not necessarily has the significance of a
> "store" request (could be informative, or for requesting validation).
> * Introduce a direct communication method in both directions
> (OP<->RP), supported via discovery, for bulk exchange of attributes
> about (potentially) multiple users.
>
>
> IV. Specifications
>
> OpenID Attribute Exchange 2.0
>
>
> V. Anticipated audience
>
> All those interested in the obtaining attributes about users
> authenticated via OpenID.
>
>
> 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 Attribute Exchange 2.0 spec final draft is delivered and the form
> of management and maintenance of the registry is established.
>
>
> Background Information
> I. Related Work
>
> Attribute Exchange (1.0), and Simple Registration.
> II. Initial Membership
>
> * Tom Allen, a...@yahoo-inc.com. Yahoo! Inc (editor)
> * Mike Graves, mgra...@janrain.com, JanRain, Inc.
> * Dick Hardt, d...@skip.com. Sxip Identity.
> * Breno de Medeiros, br...@google.com. Google, Inc. (editor)
> * Hideki Nara, hd...@ic-tact.co.jp, Tact Communications
> * Nat Sakimura, n-sakim...@nri.co.jp (editor)
>
>
>
>
> --
> --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
>   

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

Re: Request for consideration of Working Group Charter Proposal

[Allen Tom]

Hi Nat - I'm not quite sure what you mean by "class".

Breno, Dick, Eran, and I had a conversation about AX earlier this month 
where discussed the ability for AX to define objects or collections of 
attributes, as opposed to just simple key/value pairs. Is this what 
you're referring to? If so, then this should be in scope.


Allen


Nat Sakimura wrote:
+1 but where does the "class" in the earlier post of mine fits into in 
the scope?  



On Sat, Dec 20, 2008 at 6:16 AM, Breno de Medeiros <mailto:br...@google.com>> wrote:


siiigh. That is what senility feels like.

On Fri, Dec 19, 2008 at 12:39 PM, Allen Tom mailto:a...@yahoo-inc.com>> wrote:
> +1, but I don't know who this Tom Allen is.
>
> Allen
>
>
> Breno de Medeiros wrote:
>>
>> Attribute Exchange (1.0), and Simple Registration.
>> II. Initial Membership
>>
>>* Tom Allen, a...@yahoo-inc.com <mailto:a...@yahoo-inc.com>.
Yahoo! Inc (editor)
>>* Mike Graves, mgra...@janrain.com
<mailto:mgra...@janrain.com>, JanRain, Inc.
>>* Dick Hardt, d...@skip.com <mailto:d...@skip.com>. Sxip
Identity.
>>* Breno de Medeiros, br...@google.com
<mailto:br...@google.com>. Google, Inc. (editor)
>>* Hideki Nara, hd...@ic-tact.co.jp
<mailto:hd...@ic-tact.co.jp>, Tact Communications
>>* Nat Sakimura, n-sakim...@nri.co.jp
<mailto:n-sakim...@nri.co.jp> (editor)
>>
>>
>>
>>
>>
>
>



--
--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 <mailto:specs@openid.net>
http://openid.net/mailman/listinfo/specs




--
Nat Sakimura (=nat)
http://www.sakimura.org/en/


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

Re: Request for consideration of Working Group Charter Proposal

[Allen Tom]

+1, but I don't know who this Tom Allen is.

Allen


Breno de Medeiros wrote:
>
> Attribute Exchange (1.0), and Simple Registration.
> II. Initial Membership
>
> * Tom Allen, a...@yahoo-inc.com. Yahoo! Inc (editor)
> * Mike Graves, mgra...@janrain.com, JanRain, Inc.
> * Dick Hardt, d...@skip.com. Sxip Identity.
> * Breno de Medeiros, br...@google.com. Google, Inc. (editor)
> * Hideki Nara, hd...@ic-tact.co.jp, Tact Communications
> * Nat Sakimura, n-sakim...@nri.co.jp (editor)
>
>
>
>
>   

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

Re: What is the status of AX 2.0 WG proposal?

[Allen Tom]

The in person chat was very productive, and I expect to move forward 
with this proposal after the holidays.


Allen

Dick Hardt wrote:

I've been busy with other things. :-)

I had an in person chat with Allen Tom, Eran and Breno about what they 
were thinking of. There was some discussion on the step2 list.


I have a work item to write up the scope so that we can get it started 
-- but have needed to deal with some time critical tasks before I 
could start on it -- sorry.


-- Dick

On 17-Dec-08, at 4:56 PM, Nat Sakimura wrote:


I am very interested in it, but have not heard about it for sometime.

What is the status right now?

--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
specs@openid.net <mailto: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: Completing the SREG 1.1 specification

[Allen Tom]

Yes, the idea is to pass an URL to the the user's profile pic. I'm not 
sure if the resolution/aspect ratio needs to be communicated. Also, is 
the RP expected to download and cache the profile pic, or should it link 
directly to it? This needs to be clarified in the spec.

+1 for adding additional URLs which are associated with the user. This 
could be helpful for identity consolidation.
Allen


Sam Alexander wrote:
> +1 for adding a profile pic to the SREG 1.1 spec.
>
> Allen, I'm assuming you mean including a URI to the profile pic as 
> opposed to something like a base64 encoded jpeg or something else 
> totally awesome like that :)
>
> Also, having a "homepage" or "website" URI would be another great 
> field addition.  This would be a URI that pointed to a blog, homepage, 
> additional OpenID or other URI that the user would like to provide.
>
> I agree that the strength of SREG is its constrained fields.  These 
> two additions would allow ALOT of value to the spec, however, if they 
> were to be considered.
>
> -Sam
>
> On Dec 2, 2008, at 3:41 PM, Allen Tom wrote:
>
>> Yahoo is currently testing SREG, and we'd like to see the 1.1 SREG draft
>> updated to clarify any ambiguities before we're done testing. We'd also
>> like to see the schema updated to include the user's profile pic.
>>
>> We decided to build support for SREG before AX because SREG seems to be
>> more widely used, and also because SREG allows the RP to pass the url to
>> its privacy policy in the request. Strangely, AX does not have an
>> interface for the RP to pass its privacy policy to the OP.  We have a
>> mandatory requirement from our legal and privacy teams to be able to
>> link to the RP's privacy policy on our OpenID approval page before
>> sharing any user data with an RP.
>>
>> We'd like SREG to be updated to enable the profile pic to be in the
>> schema, and also any other cleanup that's needed for OpenID 2.0 OPs to
>> support it.
>>
>> Moving forward, we'd also like to support both SREG and AX, if AX is
>> updated to allow the privacy policy url to be included in the request.
>> Alternatively, OPs which support the OpenID/OAuth hybrid protocol can
>> just tie the privacy policy to an OAuth consumer key, assuming that the
>> OP requires pre-registered consumer keys.
>>
>> I'd be happy to help contribute to SREG and AX specs if the owners of
>> the spec would like me to.
>>
>> Allen
>>
>>
>> David Recordon wrote:
>>> I certainly want to see us push the world to implementing AX instead
>>> of SREG, though agree with Mart that there are existing
>>> interoperability problems with SREG that would be nice to fix given
>>> that large OPs are still implementing it in a broken fashion.  I'd see
>>> no issue with including in the SREG spec that people really should go
>>> use AX instead.
>>>
>>>
>>>
>>>> On 28-Nov-08, at 11:28 PM, Martin Atkins wrote:
>>>>
>>>>
>>>>>
>>>>> As long as folks still want to implement SREG, I think it's
>>>>> beneficial
>>>>> to have a specification that actually works in practice, which the
>>>>> current draft does not.
>>>>>
>>
>> ___
>> 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: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Martin Atkins wrote:
> There's also the need to have something to point at as what the user 
> trusted, so that other applications can't piggy-back off the trust of a 
> popular app.
>
>   
Hi Martin,

The OAuth access token is the credential that is issued to the instance 
of the application that was authorized. Although the SP might not be 
able to identify the application, the Access Token can be used to 
identify the instance of whatever app it was that was authorized by the 
user.

> It doesn't matter so much if the former is compromised, but it is very 
> important that the second isn't compromised.
>   
All applications are expected to secure store their Access Token Secret, 
which was issued along with the AT.

> It seems like there needs to be two tokens here. One is provisioned by 
> going through some registration flow on the SP site,
This is the OAuth Consumer Key and Consumer Secret. The CK identifies 
the application, and the CS is used to sign requests on behalf of the 
CK. Unfortunately, the CS can be easily compromised for all non-server 
based applications.

>  and the other is 
> provisioned automatically *by each installation* of a desktop/mobile 
> app. The latter is known only to that installation and so a user trusts 
> only their installation of the app, not an installation of the same app 
> on someone else's system.
>
>   
Yup, this is the OAuth Access Token and Access Token Secret.


> I guess the flow I'm imagining is as follows:
>
> * App author applies for an application identifier through web forms as 
> normal.
> * App author creates a desktop app that is distributed with that 
> application identifier embedded in it.
> * On install or first run, the app makes a back-channel request to an 
> endpoint at the SP to get a consumer key that's attached to the 
> application identifier but known only to that install.
> * Henceforth, the app does OAuth as normal using the single-instance 
> consumer key.
>
>   
I think the existing OAuth dance is pretty much equivalent (although 
different) than what you describe.

Allen

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

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Hi Martin,

The intent is to be able to identify applications which were not 
deliberately designed to be malicious. Well designed malicious apps 
would piggy back off of another app's CK or just cycle through a list of 
CKs to evade detection.

However, there have been occasions where legitimate apps behave 
strangely, and we'd like to be able to contact the developer of the app 
for more information. Having the CK present in the server logs makes it 
a lot easier for us to diagnose problems on our side, especially if 
we're able to use the CK to look up information about the app and its 
developer.

We've also seen apps that are well intentioned, but extremely buggy. 
It's very helpful to be able to easily identify requests originating 
from these apps if we need to disable them.

Allen


Martin Atkins wrote:
> If I make a dangerous app using the consumer key from a popular 
> application, would you black list that key and inconvenience all of its 
> users?
>
> (I doubt it.)
>
>   

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

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

It's definitely bad hygiene for developers to leak their secrets to the 
browser, or to reuse their website's CK for a downloadable client 
application, and we're doing all that we can to encourage good hygiene.


For the time being, we prefer to require CKs for client applications 
(even if they can't be verified) mostly to make it easy for us to pull 
the plug on specific applications if they are discovered to be severely 
buggy or dangerous. We'd also like to require pre-registration of CKs so 
that we know who to contact about a particular app if we have any questions.


Allen

Breno de Medeiros wrote:

Interesting point, and probably worth adding to a security portion of the spec.

I would say though, that is bad security hygiene to share the same
consumer key between your web and desktop apps. Since we can't vouch
for consumer keys stored in desktop apps anyway, I would volunteer
that the most sensible thing is to have empty consumer keys in that
case (and warn users that we can't vouch for the origin of the
request).

On Tue, Dec 2, 2008 at 4:37 PM, Allen Tom <[EMAIL PROTECTED]> wrote:
  

Dirk Balfanz wrote:

On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom <[EMAIL PROTECTED]> wrote:



In Section 10, and perhaps also in Section 12, the spec should mention
that because the hybrid protocol does not have a request token secret, and
because the user is never required to manually type in the request token
(unlike in OAuth), the hybrid Request Token probably should be longer and
harder to guess than the standard OAuth Request Token. At least for our
implementation, I'm thinking that the hybrid RT == OAuth's RT+RTSecret.
  

But you need to have the consumer secret to exchange it, no? What if it were
just a incrementing integer? What would the attack be?

Yes, the attacker would still need the Consumer Secret, however in vanilla
OAuth, the attacker would need the Consumer Key, Consumer Secret, Request
Token, and Request Token Secret. Because there's one less secret, the Access
Token could be more vulnerable to hijacking from brute force attacks where
RTs are just randomly scanned.

In our case, Yahoo issues relatively short Request Tokens from a limited
character set to make them easy to type. We compensate for the short RTs by
pairing them with long RTSecrets. If we were to implement the hybrid
protocol, our hybrid RTs would be much longer than the regular OAuth RTs.

We also believe that developers may inadvertently leak their Consumer
Secrets. We're seeing lots of questions from developers who are trying to
use OAuth from within Javascript and Flash, which implies that they're going
to be leaking the secret to the browser. Developers may also reuse their
website's Consumer Key into a downloadable client application.

Allen








  


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

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Dirk Balfanz wrote:


On Tue, Nov 25, 2008 at 7:17 PM, Allen Tom <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:



In Section 10, and perhaps also in Section 12, the spec should
mention that because the hybrid protocol does not have a request
token secret, and because the user is never required to manually
type in the request token (unlike in OAuth), the hybrid Request
Token probably should be longer and harder to guess than the
standard OAuth Request Token. At least for our implementation, I'm
thinking that the hybrid RT == OAuth's RT+RTSecret.


But you need to have the consumer secret to exchange it, no? What if 
it were just a incrementing integer? What would the attack be?
Yes, the attacker would still need the Consumer Secret, however in 
vanilla OAuth, the attacker would need the Consumer Key, Consumer 
Secret, Request Token, and Request Token Secret. Because there's one 
less secret, the Access Token could be more vulnerable to hijacking from 
brute force attacks where RTs are just randomly scanned.


In our case, Yahoo issues relatively short Request Tokens from a limited 
character set to make them easy to type. We compensate for the short RTs 
by pairing them with long RTSecrets. If we were to implement the hybrid 
protocol, our hybrid RTs would be much longer than the regular OAuth RTs.


We also believe that developers may inadvertently leak their Consumer 
Secrets. We're seeing lots of questions from developers who are trying 
to use OAuth from within Javascript and Flash, which implies that 
they're going to be leaking the secret to the browser. Developers may 
also reuse their website's Consumer Key into a downloadable client 
application.


Allen


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

Re: Completing the SREG 1.1 specification

[Allen Tom]

Yahoo is currently testing SREG, and we'd like to see the 1.1 SREG draft 
updated to clarify any ambiguities before we're done testing. We'd also 
like to see the schema updated to include the user's profile pic.

We decided to build support for SREG before AX because SREG seems to be 
more widely used, and also because SREG allows the RP to pass the url to 
its privacy policy in the request. Strangely, AX does not have an 
interface for the RP to pass its privacy policy to the OP.  We have a 
mandatory requirement from our legal and privacy teams to be able to 
link to the RP's privacy policy on our OpenID approval page before 
sharing any user data with an RP.

We'd like SREG to be updated to enable the profile pic to be in the 
schema, and also any other cleanup that's needed for OpenID 2.0 OPs to 
support it.

Moving forward, we'd also like to support both SREG and AX, if AX is 
updated to allow the privacy policy url to be included in the request. 
Alternatively, OPs which support the OpenID/OAuth hybrid protocol can 
just tie the privacy policy to an OAuth consumer key, assuming that the 
OP requires pre-registered consumer keys.

I'd be happy to help contribute to SREG and AX specs if the owners of 
the spec would like me to.

Allen


David Recordon wrote:
> I certainly want to see us push the world to implementing AX instead  
> of SREG, though agree with Mart that there are existing  
> interoperability problems with SREG that would be nice to fix given  
> that large OPs are still implementing it in a broken fashion.  I'd see  
> no issue with including in the SREG spec that people really should go  
> use AX instead.
>
>
>   
>> On 28-Nov-08, at 11:28 PM, Martin Atkins wrote:
>>
>> 
>>>
>>> As long as folks still want to implement SREG, I think it's  
>>> beneficial
>>> to have a specification that actually works in practice, which the
>>> current draft does not.
>>>   

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

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Some more feedback:

The first sentence in the Abstract should say "describes" instead of 
"describe."


The phrase "OpenID OAuth Extension" is not consistently capitalized in 
the spec. For instance, it's capitalized in the first sentence in 
section 3, but "extension" is lowercase in section 4.  Sections 5 and 8 
call it the OAuth extension, rather than the OpenID OAuth Extension.


The second word in Section 7, "Requesting" should be all lowercase.

In Section 7, the phrase "this extension can be used to request that the 
end user authorize an OAuth token" should probably be clarified to say 
that the user is authorizing an OAuth Access token.


In the last sentence of Section 8, the phrase "SHOULD not" should be in 
all caps, "SHOULD NOT."


I recommend that the phrase "Combined Consumer" be used instead of 
simply "Consumer" everywhere in the spec. The third paragraph in section 
9, and the description for OAuth token secret in Section 10 still say 
Consumer.


In Section 10, is the Access Token endpoint discoverable? I guess that's 
out of scope for this spec.


In Section 10, and perhaps also in Section 12, the spec should mention 
that because the hybrid protocol does not have a request token secret, 
and because the user is never required to manually type in the request 
token (unlike in OAuth), the hybrid Request Token probably should be 
longer and harder to guess than the standard OAuth Request Token. At 
least for our implementation, I'm thinking that the hybrid RT == OAuth's 
RT+RTSecret.


I think the spec is getting pretty close.

thanks
Allen




Dirk Balfanz wrote:



Otherwise, the spec is looking pretty good!


Great! We're officially calling it Draft 1 now :-) (the previous 
version was Draft 0).


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

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

A couple minor edits are needed to Section 12: Security Considerations.

I assume that the response_token in Section 12 is the same as the 
request_token in Section 9. The terminology needs to be consistent.

"Is" shoudl be changed to "are" in the phrase "The following security 
principles is reflected in this design"

Otherwise, the spec is looking pretty good!

Allen

Dirk Balfanz wrote:
>
> Ok, new version is up. I took out the sentence that recommended to 
> send a cancel. I also added a section on discovery (just copied 
> whatever the AX extension says about that).
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

How about if the openid.oauth.scope response parameter defined in 
Section 9 be changed to be a more generic OAuth status indicator? It can 
be used to indicate which scopes were authorized in the success case, or 
it can be used as status/problem indicator if there was an error.


Perhaps the allowed values can be the same as the values defined in the 
ProblemReporting extension.

http://oauth.pbwiki.com/ProblemReporting

Allen




Dirk Balfanz wrote:



On Wed, Nov 19, 2008 at 2:31 PM, Allen Tom <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:


Since the new hybrid draft spec doesn't affect the OpenID
association method, this is moot.

However, the spec should mention what SPs should do if the CK is
invalid (or doesn't match the realm) in the OpenID authentication
request. Presumably, the SP should continue servicing the OpenID
portion of the request, however, the response should indicate why
the OAuth portion of the request failed.


How about, to mimic what happens with association handles, we can 
return in the response an openid.oauth.invalid_consumer parameter 
instead of openid.oauth.consumer? It would mean that either the CK was 
just wrong or that it didn't match the realm. Although at this point 
it starts to get pretty complicated. 

Does this error condition really need to be communicated back to the 
RP? For development etc., it might be enough to just show an error 
page to the user explaining what happened. 


Dirk.

 



Allen



Dirk Balfanz wrote:



I'd recommend an error consistent with Section 8.2.4 in the
OpenID 2.0 spec, with a new error_code value indicating that
the either the CK or the realm was invalid. There may
actually need to be 2 errors, one to indicate that the CK is
invalid, and another to indicate that the CK is not valid for
the realm.

http://openid.net/specs/openid-authentication-2_0.html#anchor20


But Section 8.2 is about the association response. In the auth
response, we currently only have cancel or setup_needed. If we
invent another error condition there, we're no longer a pure
"extension". 
 





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

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Since the new hybrid draft spec doesn't affect the OpenID association 
method, this is moot.


However, the spec should mention what SPs should do if the CK is invalid 
(or doesn't match the realm) in the OpenID authentication request. 
Presumably, the SP should continue servicing the OpenID portion of the 
request, however, the response should indicate why the OAuth portion of 
the request failed.


Allen


Dirk Balfanz wrote:



I'd recommend an error consistent with Section 8.2.4 in the OpenID
2.0 spec, with a new error_code value indicating that the either
the CK or the realm was invalid. There may actually need to be 2
errors, one to indicate that the CK is invalid, and another to
indicate that the CK is not valid for the realm.

http://openid.net/specs/openid-authentication-2_0.html#anchor20


But Section 8.2 is about the association response. In the auth 
response, we currently only have cancel or setup_needed. If we invent 
another error condition there, we're no longer a pure "extension". 
 


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

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Hi Martin,

Not sure why you say that requiring pre-registration and having an open 
stack are mutually exclusive. Are you saying that there's no benefit for 
service providers to provide a standard interface to developers?

Allen


Martin Atkins wrote:
> Allen Tom wrote:
>>
>> One  problem with this approach is that many SPs like Yahoo and 
>> MySpace will require developers to register their site to get a 
>> Consumer Key. Given that the developer already has to manually get a 
>> CK, there might not that much value in defining a workflow for 
>> Consumers to discover the OAuth endpoints.
>>
>
> As long as this is true it will be impossible for such SPs to expose 
> non-proprietary protocols like PortableContacts, so either these SPs 
> will need to find a way to work without pre-registration or we'll all 
> have to accept that the open stack is impossible and go find something 
> more productive to do.
>

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

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Dirk Balfanz wrote:
> Ok, new spec is up: 
> http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html
>
>
>

Hi Dirk,

It doesn't look like the hybrid spec changes the OpenID association 
mechanism, so you should not mention the association mechanism in the 
last sentence of Section 3.

Under Security Considerations in Section 11, it would probably be good 
to mention that anyone knowing the CK can force the SP to display the 
hybrid approval page, while standard OAuth requires both the CK and the 
CSecret  to display a vanilla OAuth approval page.

Thanks
Allen


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

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Manger, James H wrote:
> Ideally, an app would attempt to access a protected resource at an SP and get:
> * A 401 Unauthenticated response from the SP; with
> * A “WWW-Authenticate: OAuth” header; with
> * A parameter providing the authorization URL; and
> * Another parameter with the OP URL (when OpenID/OAuth hybrid was supported).
>   

One  problem with this approach is that many SPs like Yahoo and MySpace 
will require developers to register their site to get a Consumer Key. 
Given that the developer already has to manually get a CK, there might 
not that much value in defining a workflow for Consumers to discover the 
OAuth endpoints.

Allen



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

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Dirk Balfanz wrote:
>
> Oh I see. Ok. I'l make a new revision of the spec where I add a 
> required parameter (the consumer key) to the auth request.
>
Cool, thanks!


> What should the spec recommend the OP should do if the consumer key 
> and realm don't match? Return a cancel? Return something else?
>
I'd recommend an error consistent with Section 8.2.4 in the OpenID 2.0 
spec, with a new error_code value indicating that the either the CK or 
the realm was invalid. There may actually need to be 2 errors, one to 
indicate that the CK is invalid, and another to indicate that the CK is 
not valid for the realm.

http://openid.net/specs/openid-authentication-2_0.html#anchor20

Allen

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

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Sadly, because the OpenID authentication request is not signed, the CK 
can't be authenticated, but as you pointed out, although the user may 
authorize the application, the CK secret is still required to fetch the 
credentials. The worst that could happen is that a user will authorize 
an impostor, but the impostor will not be able to retrieve the token.

That being said, in our case, the CK contains additional information 
besides the scope. Yahoo's OAuth Permissions screen contains a lot of 
rich information including the application's name, description, 
developer(s), images, authorization lifetimes, etc. Over time, new 
fields may be added to the approval page.

While it might make sense for the application's scope to be passed in at 
authorization time, does it also make sense to define new parameters for 
all the other application specific metadata? The actual data that needs 
to be displayed on an approval page is very SP specific, and some SPs 
may have security/legal policies requiring that all metadata is manually 
reviewed, which makes it impossible for metadata to be passed in at runtime.

So that's why SPs may need the CK in order to display the Approval page. 
Make sense?

Allen



Dirk Balfanz wrote:
>
> Need to know the CK for what? What purpose would hinting at the CK 
> serve (since it wouldn't prove ownership)? And don't say "scope" :-)
>

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

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Dirk Balfanz wrote:
>
> So, again, the proposal seems to be to embed a hint to the consumer 
> key into the association request (which will then be threaded through 
> the association handle into the auth request). This doesn't buy us any 
> additional security, it just hints at what scope the consumer is 
> allowed to request (for those SPs that encode scope in consumer keys) 
> - the security is provided later in the access token request step.
>
It's unfortunate that the OpenID Authentication request isn't signed, 
because if it was signed, it would be nearly equivalent to OAuth, 
because an OAuth approval page is only displayed using a valid Request 
Token that was returned via a signed request.

> Now, my argument is that we already _have_ a place to signal scope. 
> It's the openid.oauth.scope parameter.

Yes, but as Breno said, the OAuth spec does not currently have a concept 
of scope, however, the Consumer Key is definitely part of the spec. It 
would seem to be more generally useful for a Consumer to signal Consumer 
Key, rather than signaling scope, as many SPs need to know the CK, but 
not all of them will need to know the scope. That being said, the CK and 
Scope should just be 2 separate parameters.



> If you don't want to put consumer keys there, let consumers put some 
> other encoding of the scope there.
I have no problem with having an optional parameter for CK, and a 
different optional parameter for scope. 

Allen


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

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

In the future, we might update our OAuth service to allow developers to 
pass us the scope dynamically, rather than binding the scope to the CK. 
However, we'd still probably require developers to agree to a TOS in 
order to get a CK/CS.

I'm concerned about having to tell developers to pass the CK via the 
scope parameter for the first revision, and then later telling them that 
scope parameter actually means the scope. I'd like to have one parameter 
(possibly optional) that means CK, and another parameter (also optional) 
that means Scope. Overloading a single parameter can get really messy in 
the long run.

Allen







Breno de Medeiros wrote:
> Ok, but what is wrong for you to instruct the developers to insert the
> consumer_key in the scope parameter, and they bind it to the approved
> request token?
>   

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

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Adding OAuth signature methods, including RSA-SHA1, to OpenID 2.1 is 
supposed to happen. It is probably not a good idea to return RSA keys 
via association requests for unregistered consumers though.


Allen


Breno de Medeiros wrote:

2008/11/13 Allen Tom <[EMAIL PROTECTED]>:
  

In the registered consumer case, why not just do:

openid.assoc_handle=consumer_key
openid.mac_key=consumer_secret



This implies that the consumer key is HMAC-SHA1. What if it is RSA?

  

?

In the unregistered consumer case, the OpenID association request could be
extended to hand out Consumer keys, which are then used as the association
handle. The scopes and realm could be passed to the association request as
well.


Allen



Dirk Balfanz wrote:

Yes, I can see how that would happen.

So how about for OPs who tie scope to Consumer Keys, their
openid.oauth.scope syntax would look something like this:

openid.oauth.scope=consumer_key:scope1,scope2,scope3

Or, if there is a one-to-one mapping from consumer_key to scope, simply like
this:

openid.oauth.scope=consumer_key

Dirk.

On Thu, Nov 13, 2008 at 2:04 PM, Darren Bounds <[EMAIL PROTECTED]> wrote:


Certainly but the consumer context you display to the user is falsely
represented based solely on the realm in that circumstance.

Sent from a mobile device.
On Nov 13, 2008, at 4:58 PM, Dirk Balfanz <[EMAIL PROTECTED]> wrote:



On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom <[EMAIL PROTECTED]> wrote:
  

Dirk Balfanz wrote:


I don't think this is true - I believe the realm is sufficient. Let me
try and explain. (We'll assume registered consumers.) On the approval page,
we need to identify the consumer. In its current form, the spec basically
assumes that you're gonna use the realm for that.
  

You're assuming that a realm has only one CK. A site might have multiple
consumer keys, with different scopes attached to them...


Actually, I wasn't assuming that. At access token request time, you follow
the map from consumer-key to realm (that's the direction you can do, right)?
If that's a many-to-one map then this will give you one realm. Then you
check whether that's the realm that the request token was issued to.

The one thing you're losing is that you can't, at approval time, figure
out whether that realm is requesting a scope that they have access to. So a
realm could ask for a certain scope in their auth request, the user approves
it, and then at access-token-request time, you won't issue the token b/c
they're using a CK that doesn't have enough privileges. It's still secure,
but gives you a crappy user experience if the consumer mixes up their CKs.

Wait - I think I have an idea: what if the Yahoo-specific way of
requesting the scope is to include the CK into the openid.oauth.scope
parameter? That way, you can at approval time make sure that they are
requesting a scope that they are actually authorized to pick up. This
wouldn't be for security purposes - just as a way to make sure the user
experience isn't surprising.

Dirk.

___
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: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

In the registered consumer case, why not just do:

openid.assoc_handle=consumer_key
openid.mac_key=consumer_secret

?

In the unregistered consumer case, the OpenID association request could 
be extended to hand out Consumer keys, which are then used as the 
association handle. The scopes and realm could be passed to the 
association request as well.



Allen



Dirk Balfanz wrote:

Yes, I can see how that would happen.

So how about for OPs who tie scope to Consumer Keys, their 
openid.oauth.scope syntax would look something like this:


openid.oauth.scope=consumer_key:scope1,scope2,scope3

Or, if there is a one-to-one mapping from consumer_key to scope, 
simply like this:


openid.oauth.scope=consumer_key

Dirk.

On Thu, Nov 13, 2008 at 2:04 PM, Darren Bounds <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:


Certainly but the consumer context you display to the user is
falsely represented based solely on the realm in that circumstance.


Sent from a mobile device.

On Nov 13, 2008, at 4:58 PM, Dirk Balfanz <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:




On Thu, Nov 13, 2008 at 1:45 PM, Allen Tom <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:

Dirk Balfanz wrote:


I don't think this is true - I believe the realm is
sufficient. Let me try and explain. (We'll assume
registered consumers.) On the approval page, we need to
identify the consumer. In its current form, the spec
basically assumes that you're gonna use the realm for that.


You're assuming that a realm has only one CK. A site might
have multiple consumer keys, with different scopes attached
to them...


Actually, I wasn't assuming that. At access token request time,
you follow the map from consumer-key to realm (that's the
direction you can do, right)? If that's a many-to-one map then
this will give you one realm. Then you check whether that's the
realm that the request token was issued to.

The one thing you're losing is that you can't, at approval time,
figure out whether that realm is requesting a scope that they
have access to. So a realm could ask for a certain scope in their
auth request, the user approves it, and then at
access-token-request time, you won't issue the token b/c they're
using a CK that doesn't have enough privileges. It's still
secure, but gives you a crappy user experience if the consumer
mixes up their CKs.

Wait - I think I have an idea: what if the Yahoo-specific way of
requesting the scope is to include the CK into the
openid.oauth.scope parameter? That way, you can at approval time
make sure that they are requesting a scope that they are actually
authorized to pick up. This wouldn't be for security purposes -
just as a way to make sure the user experience isn't surprising.

Dirk.

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





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

Re: OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

Dirk Balfanz wrote:
>
> I don't think this is true - I believe the realm is sufficient. Let me 
> try and explain. (We'll assume registered consumers.) On the approval 
> page, we need to identify the consumer. In its current form, the spec 
> basically assumes that you're gonna use the realm for that.

You're assuming that a realm has only one CK. A site might have multiple 
consumer keys, with different scopes attached to them...

Allen


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

OpenID/Oauth hybrid [was Re: specs Digest, Vol 27, Issue 3]

[Allen Tom]

enID OAuth Extension 1.0. Spec completion by Q4 2008.


Anticipated audience or users of the work:
 - OpenID Providers and Relying Parties
 - OAuth Consumers and Service Providers
 - Implementers of OpenID Providers and Relying Parties


Language in which the WG will conduct business:
English.


Method of work:
E-mail discussions on the working group mailing list and working group
conference calls.


Basis for determining when the work of the WG is completed:
The work will be completed once it is apparent that maximal
consensus on the
protocol proposal has been achieved within the working group,
consistent
with the purpose and scope.


Proposers:
 - Ben Laurie, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>, Google
 - Breno de Medeiros, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>,
Google
 - David Recordon, [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>, Six Apart
 - Dirk Balfanz, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>,
Google
 - Joseph Smarr, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>, Plaxo
 - Yariv Adan, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>, Google
 - Allen Tom, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ,
Yahoo
 - Josh Hoyt, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> , JanRain


Initial Editors:
 - Dirk Balfanz, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>,
Google  - Breno de Medeiros,
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>, Google


--
Yariv Adan | Product Manager
Google Switzerland GmbH | Identifikationsnummer: CH-020.4.028.116-1
This e-mail is confidential. If you are not the right addressee
please do
not forward it, please inform the sender, and please erase this e-mail
including any attachments. Thanks.
-- next part --
An HTML attachment was scrubbed...
URL:

http://openid.net/pipermail/specs/attachments/20081103/21c48c00/attachment.html

--

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

End of specs Digest, Vol 27, Issue 3





--
Yariv Adan | Product Manager
Google Switzerland GmbH | Identifikationsnummer: CH-020.4.028.116-1
This e-mail is confidential. If you are not the right addressee please 
do not forward it, please inform the sender, and please erase this 
e-mail including any attachments. Thanks.  



___
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: Login Federation

[Allen Tom]

expires_in only specifies the lifetime of an association handle. There's 
no parameter that indicates the lifetime of an authentication response.


Allen


Martin Paljak wrote:

On Feb 18, 2008, at 5:11 PM, McGovern, James F (HTSC, IT) wrote:
  

Likewise, I would think that for automatic signon, it would be a good
thing if the OpenID provider could tell the relying party how long to
leave an otherwise idle session open before timing it out. Not sure if
this would require an extension or not.



expires_in from http://openid.net/specs/openid-authentication-2_0.html#anchor20 
  should do exactly this.


m.
  


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

Re: Realm spoofing spec patch

[Allen Tom]

Hi Josh,

Having the OP verify the realm/return_to as part of the Authentication
Request is fine. OPs should cache the verifcation status to reduce
latency for RPs that send many users to the OP.

At least from my perspective, it always seemed odd that the Association
Request is just an interface for OPs to return shared secrets and
association handles without knowing anything about the requestor, except
for the IP address. I always thought that RPs should pass some
information about themselves to the OP when requesting association so
that an OP can bind an association handle with an RP.

Anyway, I don't think there's any pressing need to change the
association request interface at this time.

Thanks!
Allen




> Allen,
> 
> On 5/29/07, Allen Tom <[EMAIL PROTECTED]> wrote:
> > From an implementation perspective, it might make sense for the OP to
> > verify the RP during the association request, so that the association
> > handle is only returned after the RP has been verified.
> 
> Were you concerned about implementation complexity or the time it
> could take to do discovery while the user is waiting?
> 
> At association time, the provider does not know who the relying party
> is. Are you proposing that the realm be included in the association
> request? In that case we'd have to include the discovery URL, in the
> case of a wildcard realm.
> 
> I see two potential problems:
> 
>  1. If the discovery happens during the association request, a
> single-threaded relying party might not respond to the
> verification request. This wouldn't come up too frequently in
> production, but it would raise the bar for example and prototype
> code.
> 
>  2. If the form of a return_to URL changes (and the relying party
> updates the discovery information to match) it would be good if
> the provider could attempt verification again, so that a valid
> request could complete successfully.
> 
> (2) requires the same flow as the proposed implementation
> (verification during the course of the request), and so I think it's
> simpler to just leave it in-band. I suppose that the specification
> could remain silent on *when* to perform the verification, since it
> doesn't really matter from a security perspective, which would leave
> both channels open, as long as the pertinent information was added to
> the association request.
> 
> Josh
> 
> 


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

RE: Realm spoofing spec patch

[Allen Tom]

Josh - thanks for writing this up!

David - Many OPs may choose not to let their users login into RPs that
can't be verified. For instance, in the case where a large corporation
like Sun issues their employees OpenIDs, the corporation may want to be
very selective as to which RPs they let their employees sign into.

An OP that is targeting mass market/consumer users may instead want to
sternly warn their users that the RP can't be verified, similar the
warning that browsers display when there are issues with the cert when
using HTTPS. 

I'd expect that if the realm spoofing patch is included in the core
protocol, and if large OPs were to implement RP endpoint discovery, then
most RPs have a very strong incentive to implement this in order to
supress the ugly warning. The solution discussed at IIW and proposed by
Josh should be trivial for all serious RPs to implement. If all serious
RPs and most of the others implment this, then the OP warning should
really be a very rare exception rather than the rule.

David - you are correct in that there is a larger problem around trust
between OPs and RPs, but this can probably be solved via out of band
pre-association. Unfortunately, this process would probably be very
heavyweight and not be easy to automate, and would probably be reserved
for parties that have some sort of business and contractual
relationship. There is no need to have something this heavyweight in the
spec as the process would probably be very proprietary and RP/OP specific.

In the interest of interoperability and ease of implementation, the
proposed solution is very lightweight and does seem to solve the
problem. It would be great if this patch be included in the core spec,
and not as an extension.

>From an implementation perspective, it might make sense for the OP to
verify the RP during the association request, so that the association
handle is only returned after the RP has been verified.

Thanks!
Allen


> It seems that this methodology only works if either:
>  1) Every site (RP or proxy) publishes their return_to endpoints or that
> they don't have any.
>  2) An OP refuses to let the user login to a RP which doesn't publish
> their return_to endpoint.
> 
> I'm unconvinced that either of those situations will actually become
> prevalent and thus worried about the effectiveness of this methodology.
> 
> Using the same example from IIW, I am logging into
> http://evilrp.com/return_to which is proxying itself through
> http://www.google.com/translate/.  If my OP were to prompt me, "We're
> unable to verify the site
> (http://www.google.com/translate/?http://evilrp.com/return_to) you're
> logging into, you should use caution when proceeding" I'm unsure how
> many users would actually not proceed, or rather see "google.com" and
> decide it is alright.
> 
> I guess since we're unable to fully resolve this issue from a technical
> perspective, and no I don't have a better technical solution, I'm
> wondering if this should actually be an extension to the core protocol
> versus seeming like a resolution to the problem when it really doesn't
> completely solve it.  In some senses I see this as a larger problem
> around trust of Relying Parties.  

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

Re: Proposal for Recycling Identifiers in OpenID 2.0

[Allen Tom]

Hi Dick,

I'm very glad to see that we're making progress in resolving the OpenID
recycling issue. 

It would seem to make sense to embed the fragment into the document
referenced by the OpenID, however in the interest of keeping the OP
discovery implementation simple and robust, I'd be in favor of adding
another parameter in the  of the document rather then having the
RP attempt to parse the body of the page for an  tag that matches the
fragment. 

In OpenID 2.0, embedding the fragment into the OpenID document might not
be necessary since the OP can just return it in the Auth Response.

It might make sense for the fragment to be a timestamp indicating when
the OpenID was first registered, perhaps even in human readable format.
For instance http://user.myopenid.com#2006-02-25 could indicate that the
OpenID http://user.myopenid.com was registered on Feb 25, 2006. 

Allen






> 
> Does the document need to contain "http://openid.op.com/user#7356";  
> for the RP to close the circle on what the OP is stating?

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