Re: OpenID Connect with custom protocol handlers in browser

[Nat Sakimura]

I still do not grasp the problems properly.

1)  I did not quite get the privacy problem. Could you explain it a bit
more fully?

2) Why two full redirects always?

3) OIDC dies use custom scheme for Self-issued OP. Have you checked that?



2019年1月20日(日) 0:30、senya さん（se...@riseup.net）のメッセージ:

> Hello!
>
> I want to say it just in case that I still don't have a solution to the
> problem I described in the above messages, so any suggestions are welcome.
>
> senya
> 25.12.2018 11:01, senya пишет:
>
> Oh, I see. So It's possible that AccountChooser does the server resolution
> even when this server was never known before by the authorization client?
> Because you wrote
>
> > AccountChooser presents the list of IdPs that the user has used against
> the domain and let her chose it
>
> And I understood that like I have to discover the IdP in advance.
>
> I think you understood my use case correctly.
>
> Well, the problem with the solution you propose (with AccountChooser) is
> that I have to implement some discovery-specific support on the diaspora
> site. The way the custom protocol handlers work, the authorization client
> can redirect to the custom protocol address from the login page (e.g. the
> AccountChooser). And in order to use this to resolve the remote host
> (diaspora) the IdP has to redirect it back to the original service. So when
> I redirect to "web+diaspora://authenticate" from the AccountChooser in
> order to resolve the target host I'll have to redirect back from diaspora
> to the URL of the authorization client with the host name in the request
> parameters. And only after that I can do the OIDC authorization flow.
>
> Besides the fact that this way I'll have two redirect-callback rounds
> between the same two services, it also has some privacy issues, because
> implementing an endpoint which unconditionally redirects back and telling
> your diaspora server host name can be used to identify the host name even
> when user doesn't want it. This issue can be solved by asking the user at
> the diaspora site something like "Do you want to tell example.com your
> host name?" but this would also mean that the user will be asked twice:
> once for the host name and second time for the OIDC authorization
> permission which is a terrible UX.
>
> That's why I looked at the "implicit registration flow" which actually
> combines this two things into one redirect-callback round: it redirects to
> the custom protocol URL and then goes back to the authorization client with
> the authorization response. If the user refused the authorization we can
> redirect without telling the hostname which solve the privacy concern.
>
> Thanks for the detailed response, though!
> 25.12.2018 10:13, n-sakimura пишет:
>
> Hmmm. Then I am not understanding your use-case properly.
>
> What I understood was as follows:
>
>
>
>- There is a diaspora user who wants to login to a service.
>- However, diaspora being distributed, there has to be a way to find
>out which server the user is using.
>
>
>
> So, that is the objective, right?
>
>
>
> Your proposed solution to it is to
>
>- Utilize a custom protocol handler so that the user can be redirected
>to the service.
>
>
>
> Is this correct?
>
>
>
> If so, my next question is why does it not suffice for the site to find
> out the diaspora server URL using AccountChoser? Once the client gets the
> address of the diaspora server, it can register itself to it and start the
> standard OpenID Connect flow. What is the reason that this does not work?
>
>
>
> Cheers,
>
>
>
> Nat Sakimura
>
>
>
> *From:* senya  
> *Sent:* Tuesday, December 25, 2018 4:12 PM
> *To:* n-sakimura  ; Nat
> Sakimura  
> *Cc:* openid-specs@lists.openid.net
> *Subject:* Re: OpenID Connect with custom protocol handlers in browser
>
>
>
> Yeah, but that's not what I want.
>
> 25.12.2018 9:06, n-sakimura пишет:
>
> AccountChooser presents the list of IdPs that the user has used against
> the domain and let her chose it.
>
> Then, the client receives the IdP that the user has selected so that the
> normal federated login can be done.
>
>
>
> Cheers,
>
>
>
> Nat
>
>
>
> *From:* specs 
>  *On Behalf Of *senya
> *Sent:* Tuesday, December 25, 2018 3:44 PM
> *To:* Nat Sakimura  
> *Cc:* openid-specs@lists.openid.net
> *Subject:* Re: OpenID Connect with custom protocol handlers in browser
>
>
>
> Hello, Nat.
>
> Thanks for the link, but however I can't see how it overlaps with my use
> case. AccountChooser / OpenYOLO seem to describe something 

Re: OpenID Connect with custom protocol handlers in browser

[Nat Sakimura]

TL;DR but your usecase seems to somewhat overlap with AccountChooser /
OpenYOLO. Have you checked them?

https://openid.net/wg/ac/

Cheers,

Nat

2018年12月24日(月) 3:15、senya さん（se...@riseup.net）のメッセージ:

> Hello!
>
> I'm trying to figure out if it is possible to implement OpenID Connect
> client authorization using a custom protocol handler registered by a
> user in browser.
>
> I'm a software developer and I'm researching the possibility of
> implementing "sign in with diaspora*" feature for 3rd party websites to
> authenticate with  diaspora* federated social network accounts.
> Diaspora* supports OIDC with the Dynamic Client Registration extension.
>
>
> Imagine there is a federated web service, which has different web entry
> points. Imagine that this federated service supports custom protocol
> handler. For example diaspora* supports registering `web+diaspora://`
> protocol handler using `registerProtocolHandler`
> [
> https://developer.mozilla.org/ru/docs/Web/API/Navigator/registerProtocolHandler
> ]
> browser API call.
>
> Each user has a specific entry point to this federated service, i.e. a
> website where the user has login credentials. Users can register a
> custom protocol handler for their entry points and when the user follows
> the custom protocol link, the link will be opened on the correct web
> site for this user. The login credentials represent the user's identity
> in the federated service.
>
> My question is: whether it is possible to use OpenID Connect to
> implement "sign in with" feature for 3rd party clients to allow users to
> sign in using the user's federated identity with using the custom
> protocol handlers to discover the entry point?
>
> I did some research, but I didn't find an answer.
>
> What I expect is that when a user requests "sign in with diaspora*"
> button at the 3rd party web site, the browser redirects this request to
> the custom protocol URI, which is resolved by the web browser and opened
> on the proper federated service node, where the authorization will
> happen and the redirected back to the 3rd party site using the
> `redirect_url` according to OpenID Connect.
>
> So the main difference from most of the OpenID Connect authorization
> providers is that the real address of the authorization providers is not
> known in advance. However we suppose that the user has registered a
> custom protocol handler in their browser. If we use the custom protocol
> link at the authorization phase, then the user's web browser will
> redirect the request to the correct web node. The first problem here is
> that you can't use a preshared secret to identify the 3rd party site
> because the nodes are not predefined.
>
> I discovered the "OpenID Connect Federation"
> [https://openid.net/specs/openid-connect-federation-1_0.html]
> specification draft which covers so called "Implicit registration". This
> allows to register the OIDC client at the time when the authorization
> request is made. This partially solved this problem. So when OIDC client
> uses a custom protocol URI as an authorization endpoint, the
> authorization provider will receive this request and then discover the
> OIDC client using the dynamic registration protocol.
>
> So for example when you push the "sign in with diaspora*" button you're
> being redirected to `web+diaspora://authenticate?authorization_params`
> which is resolved for you into the
> `
> https://your-federation-node.tld/link_handler?url=authenticate?authorization_params`
> 
> URL which is then requested and upon the request the original OIDC
> client is being discovered.
>
> By using this technique I managed to pass the authorization phase.
> However there another problem arose. I don't know how is it possible to
> pass the real host name of the OIDC auth provider back to the OIDC client.
>
> In a simple setup when authorization is successful authorization result
> is a code. However in my example, if we respond to the OIDC client with
> a code, the OIDC client will not know where this code came from. This is
> because the authorization request was sent to the custom protocol URI,
> not the real URI. The only source of the information here is HTTP
> referrer of the authorization callback which cannot be relied upon.
>
> I found this document
> [
> https://openid.net/specs/openid-financial-api-jarm-ID1.html#the-jwt-response-document
> ]
> which describes replying to authorization request using a JWT token
> which includes the `iss` (issuer) field, which can be used to identify
> the actual node of the federated service. However the same document states:
>
> > Assumption: the client remembers the authorization server to which it
> sent the authorization request and binds this information to the user
> agent.
>
> > The client obtains the iss element from the JWT and checks whether its
> value is well known and identifies the expected issuer of the
> authorization pro

RE: Essential claims with the scope value openid

[Nat Sakimura]

Right. It is called the principle of PII  collection minimization. It is one
of the main principle of GDPR / ISO 29100. 

 

 

--

PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.

 

From: specs [mailto:openid-specs-boun...@lists.openid.net] On Behalf Of John
Bradley
Sent: Wednesday, August 9, 2017 12:10 AM
To: openid-specs@lists.openid.net
Cc: openid-specs...@lists.openid.net Ab 
Subject: Re: Essential claims with the scope value openid

 

 

One School of thought (GDPR) is that you can only ask for claims that are
required.   That is why it is essential as all are required.  

 

The openID scope should only return subject and issuer.   You need to ask
for the specific claims that you want if you don't want all the claims in a
scope like profile.  

 

So it sounds like a bug in the test.  

 

John B.  

 

On Aug 8, 2017 7:49 AM, "Hasini Witharana" mailto:hasinidila...@gmail.com> > wrote:

Hi,

Currently I am working with OpenID Connect Certification basic profile. In
the OP, I have configured some claims to be gained when the scope is openid.
When I send a authorization request with  an essential claim I will get all
claims for openid and the essential claim. In the specifications there is
no, rule as It should return only the essential claim. "OP-claims-essential"
test is failing because unexpected claims are returned. Can you please
clarify this issue?



-- 

Hasini Witharana

Undergraduate | Department of Computer Science and Engineering

University of Moratuwa

Linkedin  


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

 

 

 

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

Notice of Vote for Implementer's Draft of "Financial API - Part 1: Read Only API Security Profile"

[Nat Sakimura]

FYI, the Vote for implementer’s draft of Financial API – Part1: Read Only
API Security Profile was announced at 

http://openid.net/2017/01/20/notice-of-vote-for-implementers-draft-of-financ
ial-api-part-1-read-only-api-security-profile/

The official voting period will be between Friday, February 3 and Friday,
February 10, 2017, following the 45 day review of the specification. For the
convenience of members, voting will actually open a week before Friday,
February 3 on Friday, January 27 for members who have completed their
reviews by then, with the voting period still ending on Friday, February 10,
2017.
The Financial API (FAPI) working group page is http://openid.net/wg/fapi/.
If you’re not already a member, or if your membership has expired, please
consider joining to participate in the approval vote. Information on joining
the OpenID Foundation can be found
at https://openid.net/foundation/members/registration.

The vote will be conducted
at https://openid.net/foundation/members/polls/106.


--
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender  and delete this e-mail.



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

Inaugural Meeting of FAPI Working Group

[Nat Sakimura]

Dear technical community members:

Inaugural meeting of the Financial API Working Group (FAPI WG) will be held
at 3pm CST on June 6, at the New Orleans Marriott.

Anybody who executed the IPR Contribution Agreement for the WG is welcome
to join.

Details on the room assignments etc. will be delivered later.

Best,

Nat Sakimura
-- 
Nat Sakimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Review of Proposed Implementer’s Draft of OpenID 2.0 to OpenID Connect Migration Specification

[Nat Sakimura]

No. 

Perhaps we can add a descriptive note in the Final but there is no normative 
change. 

Nat

On Sat, 4 Oct 2014 23:33:48 +
Mike Jones  wrote:

> Nat, should this comment result in an editorial correction to the
> draft before it’s republished?
> 
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Saturday, October 04, 2014 8:12 AM
> To: Nat Sakimura
> Cc: Mike Jones; sp...@lists.openid.net
> Subject: Re: Review of Proposed Implementer’s Draft of OpenID 2.0 to
> OpenID Connect Migration Specification
> 
> Hi Nat,
> Am 24.09.2014 15:49, schrieb Nat Sakimura:
> 
> ...
> 
> 
> "There could be an attack by a malicious RP to obtain the user’s PPID
> for another RP to perform identity correlation. To mitigate the risk,
> the OP MUST verify that the realm and RP’s Redirect URI matches as
> per Section 9.2 of OpenID 2.0 [OpenID.2.0]."
> 
> I'm not sure what this means. Does it mean the RP's XRDS document
> must contain the RP’s Redirect URI (a OAuth/OIDC redirect_uri)? If
> so, is the RP supposed to use a certain service Type or
> "http://specs.openid.net/auth/2.0/return_to";<http://specs.openid.net/auth/2.0/return_to>?
> 
> Example:
> 
>   http://specs.openid.net/auth/2.0/return_to
>   http://consumer.example.com/return
> 
> 
> It just means that openid2_realm MUST be (roughly) a substring of
> OpenID Connect/OAuth's Redirect URI. No XRDS is involved. Exact rule
> of the matching is given in Section 9.2 of OpenID 2.0.
> 
> It's probably nitpicking, but the OIDC redirect_uri must be matched
> using the rules given in Section 9.2 of OpenID 2.0 instead of the
> OpenId 2.0 return_to URI, correct?
> 
> best regards,
> Torsten.
> 


-- 
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd. 

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信
することを意図しております。意図された受取人以外の方によるこれらの情報の
開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール
を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受
信されたメールを削除していただきますようお願い致します。 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Review of Proposed Implementer’s Draft of OpenID 2.0 to OpenID Connect Migration Specification

[Nat Sakimura]

Thanks Torsten. 

Redirect URI is a defined term in OAuth 2.0 and thus points to the OIDC 
parameter and not that of OpenID Authentication 2.0. 
Perhaps in the Final, we can add some clarifying statements to avoid the 
confusion. 

Best, 

Nat

On Sat, 04 Oct 2014 17:11:32 +0200
Torsten Lodderstedt  wrote:

> Hi Nat,
> 
> Am 24.09.2014 15:49, schrieb Nat Sakimura:
> 
> > ...
> >
> >
> > "There could be an attack by a malicious RP to obtain the user’s
> > PPID for another RP to perform identity correlation. To mitigate
> > the risk, the OP MUST verify that the realm and RP’s Redirect
> > URI matches as per Section 9.2 of OpenID 2.0 [OpenID.2.0]."
> >
> > I'm not sure what this means. Does it mean the RP's XRDS
> > document must contain the RP’s Redirect URI (a OAuth/OIDC
> > redirect_uri)? If so, is the RP supposed to use a certain service
> > Type or "http://specs.openid.net/auth/2.0/return_to";
> > <http://specs.openid.net/auth/2.0/return_to>?
> >
> > Example:
> > 
> >   http://specs.openid.net/auth/2.0/return_to
> >   http://consumer.example.com/return
> > 
> >
> >
> > It just means that openid2_realm MUST be (roughly) a substring of 
> > OpenID Connect/OAuth's Redirect URI. No XRDS is involved. Exact
> > rule of the matching is given in Section 9.2 of OpenID 2.0.
> 
> It's probably nitpicking, but the OIDC redirect_uri must be matched 
> using the rules given in Section 9.2 of OpenID 2.0 instead of the
> OpenId 2.0 return_to URI, correct?
> 
> best regards,
> Torsten.
> 
> 


-- 
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd. 

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信
することを意図しております。意図された受取人以外の方によるこれらの情報の
開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール
を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受
信されたメールを削除していただきますようお願い致します。 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Review of Proposed Implementer’s Draft of OpenID 2.0 to OpenID Connect Migration Specification

[Nat Sakimura]

Changes are committed to bitbucket.

2014-09-25 1:11 GMT+09:00 Mike Jones :

>  If it’s all non-normative, go ahead and make the proposed changes and
> post them to bitbucket.  After the WG has a chance to review them for a few
> days, I’ll update the draft at openid.net/specs and post a note about the
> update.
>
>
>
> *From:* Nat Sakimura [mailto:sakim...@gmail.com]
> *Sent:* Wednesday, September 24, 2014 6:49 AM
> *To:* Torsten Lodderstedt
> *Cc:* Mike Jones; sp...@lists.openid.net
> *Subject:* Re: Review of Proposed Implementer’s Draft of OpenID 2.0 to
> OpenID Connect Migration Specification
>
>
>
> Thanks Torsten:
>
>
>
> Here are my reply inline.
>
>
>
> 2014-09-22 1:37 GMT+09:00 Torsten Lodderstedt :
>
> Hi Mike,
>
> here are my review comments:
>
> section 2
>
> PPID and openid2_realm:
> "If PPID was used to obtain the OpenID 2.0 Identifier" - How is the RP
> supposed to know/find out whether the OP issued a PPID or a
> universal/global OpenID? I would rather suggest to make this a mandatory
> parameter, the RP must know its OpenID 2.0 realm anyway.
>
>
>
> Amiable to it. It inherited (OPTIONAL) from OpenID 2.0 where it was
> optional as long as openid.return_to was given. From the point of view of
> locking down the IPR, I think it does not matter though so we can wait to
> fix it till after the implementer's draft.
>
>
>
>
> "If the value of openid2_id is an XRI [XRI_Syntax_2.0], the mechanism for
> verifying the iss in the ID Token is still TBD" - Do you want to determine
> this before the spec is published? If not I would suggest to replace the
> TBD by "... is out of scope for this specification."
>
>
>
> This is a bug. It is now fully specified, but I failed to remove the note
> somehow. As this is just a non-normative NOTE:, it can wait till after the
> Implementer's draft vote for the fix, IMHO.
>
>
>
>
>
>
> "There could be an attack by a malicious RP to obtain the user’s PPID for
> another RP to perform identity correlation. To mitigate the risk, the OP
> MUST verify that the realm and RP’s Redirect URI matches as per Section 9.2
> of OpenID 2.0 [OpenID.2.0]."
>
> section 3
>
> I'm not sure what this means. Does it mean the RP's XRDS document must
> contain the RP’s Redirect URI (a OAuth/OIDC redirect_uri)? If so, is the RP
> supposed to use a certain service Type or
> "http://specs.openid.net/auth/2.0/return_to";
> <http://specs.openid.net/auth/2.0/return_to>?
>
> Example:
> 
>   http://specs.openid.net/auth/2.0/return_to
>   http://consumer.example.com/return
> 
>
>
>
> It just means that openid2_realm MUST be (roughly) a substring of OpenID
> Connect/OAuth's Redirect URI. No XRDS is involved. Exact rule of the
> matching is given in Section 9.2 of OpenID 2.0.
>
>
>
>
> section 4.1.2
>
> "If a corresponding OpenID 2.0 Identifier is not found for the
> authenticated user, the openid2_id claim in the ID Token MUST have the
> value NOT FOUND." I assume the value must be "NOT FOUND"?
>
>
>
> Yes. It is going to be a verbatim string "NOT FOUND".
>
>
>
>
> section 6
>
> step 2
> "... The server SHOULD return a JSON with iss ..." Why not MUST? Otherwise
> the RP cannot verify whether the OP OP is Authoritative.
>
>
>
> The request is one of the factor for the server to decide to return the
> positive response.
>
> It may decide not to return anything for some reason, e.g., security
> doubt, and to allow this behavior, the normative text is written in SHOULD
> and not MUST.
>
>
>
>
> step 3
> "If the openid2_id does not start with http or https, it is an XRI
> [XRI_Syntax_2.0]. In this case, the RP needs to construct the verification
> URI by concatenating https://xri.net/, the value of the openid2_id claim,
> and /(+openid_iss). Requesting the resulting URI with GET will result in a
> series of HTTP 302 redirects. The RP MUST follow the redirects until HTTP
> status code 200 OK comes back. The URI that resulted in 200 OK is the
> authoritative issuer for the XRI. This URI MUST exactly match the iss in
> the ID Token except for the potential trailing slash (/) character."
>
> Doesn't this contradict the note regarding XRI in section 2 (TBD)?
>
>
>
> Right. This was the last section that I wrote, and I forgot to remove the
> TBD note.
>
> Sorry about that. The TBD NOTE shall go away.
>
>
>
>
> section 8.1
>
> "This standard allows the RP to verify the authenticity of the OpenID 2.0
> Identifier through ID Token eve

Re: Review of Proposed Implementer’s Draft of OpenID 2.0 to OpenID Connect Migration Specification

[Nat Sakimura]

Most large providers, as I understand, are using risk based authentication
and also offers two-step or two-factor authentication.
So, simply stealing password would not work: they are phishing resistant.
It looks more like a deployment issue than a protocol issue to me.
Correct me if I am wrong.

Man-in-the-browser attack is something else. It needs continuous or second
channel authentication. This looks more interesting from a protocol point
of view.

Nat

2014-09-25 2:14 GMT+09:00 Chris Drake :

>  Hi Nat,
>
> I remember back when the original OpenID was forming, and a bunch of my
> suggestions got shoved "out of scope"... which are now being brought back
> in to scope via OpenID Connect.  It's cold comfort, but at least I get to
> brag "I told you so" after the fact:-)
>
> Scratch the surface of any megahack, and 9 times out of 10 it was caused
> by phishing.  Personally, I don't see the point wasting effort on OpenID
> Connect when it's merely going to exacerbate what is already a crippling
> problem.
>
> There's a bunch of smart and experienced people on this list - they should
> put their heads together and use the power and knowledge present to fix
> what is reported at being behind 91% of the worlds security problems, most
> especially when OpenID users are significantly more vulnerable to these
> attacks, and at-risk once attacked.  "Get it right" is better than "get it
> now" IMHO.
>
> Kind Regards,
> Chris Drake
>
>
>
> Wednesday, September 24, 2014, 9:57:03 PM, you wrote:
>
>
>  The authentication mechanism itself is out of scope.
> You can, as an OP, select whatever the authentication mechanism you may
> want to use.
> OpenID Connect is concerned about transferring the information around the
> authentication event to another party.
> It is a federation protocol.
>
> Nat
>
> 2014-09-25 1:17 GMT+09:00 Chris Drake :
> Hi,
>
> Can anyone tell me if any kind of mutual-authentication or other kind of
> phishing-protection is present anywhere in the specs?
>
> Kind Regards,
> Chris Drake
>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Review of Proposed Implementer’s Draft of OpenID 2.0 to OpenID Connect Migration Specification

[Nat Sakimura]

The authentication mechanism itself is out of scope.
You can, as an OP, select whatever the authentication mechanism you may
want to use.
OpenID Connect is concerned about transferring the information around the
authentication event to another party.
It is a federation protocol.

Nat

2014-09-25 1:17 GMT+09:00 Chris Drake :

>  Hi,
>
> Can anyone tell me if any kind of mutual-authentication or other kind of
> phishing-protection is present anywhere in the specs?
>
> Kind Regards,
> Chris Drake
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Review of Proposed Implementer’s Draft of OpenID 2.0 to OpenID Connect Migration Specification

[Nat Sakimura]

mends approval of the following
> specification as an OpenID Implementer’s Draft:
>
> · OpenID 2.0 to OpenID Connect Migration 1.0
> <http://openid.net/specs/openid-connect-migration-1_0-06.html> – Defines
> how to migrate from OpenID 2.0 to OpenID Connect
>
>
>
> An Implementer’s Draft is a stable version of a specification providing
> intellectual property protections to implementers of the specification.
> This note starts the 45 day public review period for the specification
> drafts in accordance with the OpenID Foundation IPR policies and
> procedures.  This review period will end on Friday, October 31, 2014.
> Unless issues are identified during the review that the working group
> believes must be addressed by revising the drafts, this review period will
> be followed by a seven day voting period during which OpenID Foundation
> members will vote on whether to approve these drafts as OpenID
> Implementer’s Drafts. For the convenience of members, voting may begin up
> to two weeks before October 31st, with the voting period still ending on
> Friday, November 7, 2014.
>
>
>
> This specification is available at:
>
> · http://openid.net/specs/openid-connect-migration-1_0-06.html
>
>
>
> A description of OpenID Connect can be found at http://openid.net/connect/.
> The working group page is http://openid.net/wg/connect/.  Information on
> joining the OpenID Foundation can be found at
> https://openid.net/foundation/members/registration.  If you’re not a
> current OpenID Foundation member, please consider joining to participate in
> the approval vote.
>
>
>
> You can send feedback on the specifications in a way that enables the
> working group to act upon your feedback by (1) signing the contribution
> agreement at http://openid.net/intellectual-property/ to join the working
> group (please specify that you are joining the “AB+Connect” working group
> on your contribution agreement), (2) joining the working group mailing list
> at http://lists.openid.net/mailman/listinfo/openid-specs-ab, and (3)
> sending your feedback to the list.
>
>
>
> -- Michael B. Jones – OpenID Foundation Board Secretary
>
>
>
> (This notice has also been posted at
> http://openid.net/2014/09/16/review-of-proposed-implementers-draft-of-openid-2-0-to-openid-connect-migration-specification/
> .)
>
>
>
>
> ___
> specs mailing 
> listspecs@lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs
>
>
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: bug report (was: Native application SSO Working Group)

[Nat Sakimura]

Thanks!

I fixed it.

Best,

 Nat


2013/8/16 =JeffH 

>
> Hi,
>
> > Native Applications WG Web site has been set up at:
> >
> > http://openid.net/wg/napps/
> >
>
> on that above page, there's this link..
>
> http://list.openid.net/**mailman/listinfo/openid-specs-**
> native-apps<http://list.openid.net/mailman/listinfo/openid-specs-native-apps>"
> target="_blank">http://list.**openid.net/mailman/listinfo/**
> openid-specs-native-apps<http://list.openid.net/mailman/listinfo/openid-specs-native-apps>
> 
>
> ..which 404's.
>
> Note that the domain name is "list.openid.net" -- it should rather be "
> listS.openid.net"  ;-)
>
>
> There is a similar mis-link on <http://lists.openid.net/**
> mailman/listinfo/openid-specs-**native-apps<http://lists.openid.net/mailman/listinfo/openid-specs-native-apps>
> >..
>
> To see the collection of prior postings to the list,
> visit the
> http://list.openid.net/**pipermail/openid-specs-native-**
> apps/ <http://list.openid.net/pipermail/openid-specs-native-apps/>
> ">Openid-specs-native-**apps Archives.
>
>
> HTH,
>
> =JeffH
>
>
> __________**_
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/**mailman/listinfo/openid-specs<http://lists.openid.net/mailman/listinfo/openid-specs>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [OIDFSC] Native application SSO Working Group

[Nat Sakimura]

-specs-native-sso. That's the intent and the primary use
>>>> case. It will be far more appealing / understandable to the mobile
>>>> app developers than 'single authorization agent'.
>>>> -- Ashish
>>>>
>>>> On Wed, Jul 17, 2013 at 5:46 PM, Paul Madsen
>>>> mailto:paulmad...@rogers.com>**> wrote:
>>>>
>>>> oh and I guess I should have mentioned the plans for a PRISMA
>>>> subgroup ..
>>>>
>>>> On 7/17/13 7:51 PM, John Bradley wrote:
>>>>
>>>> Ok you have a point. NSAA then.
>>>>
>>>>
>>>>
>>>> I want it in red.
>>>>
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>>
>>>>
>>>> On 2013-07-17, at 7:28 PM, =JeffH
>>>>  <mailto:Jeff.Hodges@**KingsMountain.com>
>>>>  wrote:
>>>>
>>>>
>>>>
>>>>
>>>> request that the name be changed to "Native Single
>>>> Authorization Agent", with
>>>>
>>>> the mailing list name openid-specs-nssa
>>>>
>>>> but "Native Single Authorization Agent" yields "nsaa"
>>>> rather than "nssa", yes?
>>>>
>>>>
>>>>
>>>> thus "openid-specs-nsaa" ?
>>>>
>>>>
>>>>
>>>> =JeffH
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> __**_
>>>>
>>>> specs mailing list
>>>>
>>>> sp...@lists.openid.net  <mailto:sp...@lists.openid.net**>
>>>>
>>>>
>>>> 
>>>> http://lists.openid.net/**mailman/listinfo/openid-specs<http://lists.openid.net/mailman/listinfo/openid-specs>
>>>>
>>>> __**_
>>>>
>>>> specs mailing list
>>>>
>>>> sp...@lists.openid.net  <mailto:sp...@lists.openid.net**>
>>>>
>>>>
>>>> 
>>>> http://lists.openid.net/**mailman/listinfo/openid-specs<http://lists.openid.net/mailman/listinfo/openid-specs>
>>>>
>>>>
>>>>
>>>>
>>>> __**_
>>>> specs mailing list
>>>> sp...@lists.openid.net <mailto:sp...@lists.openid.net**>
>>>>
>>>> 
>>>> http://lists.openid.net/**mailman/listinfo/openid-specs<http://lists.openid.net/mailman/listinfo/openid-specs>
>>>>
>>>> __**_
>>>> specs mailing list
>>>> sp...@lists.openid.net <mailto:sp...@lists.openid.net**>
>>>>
>>>> 
>>>> http://lists.openid.net/**mailman/listinfo/openid-specs<http://lists.openid.net/mailman/listinfo/openid-specs>
>>>>
>>>>
>>>> __**_
>>>> specs mailing list
>>>> sp...@lists.openid.net <mailto:sp...@lists.openid.net**>
>>>> http://lists.openid.net/**mailman/listinfo/openid-specs<http://lists.openid.net/mailman/listinfo/openid-specs>
>>>>
>>>>
>>>
>>>
>>> __**_
>>> specs mailing list
>>> sp...@lists.openid.net
>>> http://lists.openid.net/**mailman/listinfo/openid-specs<http://lists.openid.net/mailman/listinfo/openid-specs>
>>>
>>>
>>
>> --
>> Nat Sakimura (n-sakim...@nri.co.jp)
>> Nomura Research Institute, Ltd.
>> Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
>>
>> 本メールに含まれる情報は機密情報であり、**宛先に記載されている方のみに送信 することを意図しております。**意図された受取人以外の方によるこれらの情報の
>> 開示、複製、再配布や転送など一切の利用が禁止されています。**誤って本メール を受信された場合は、申し訳ございませんが、**送信者までお知らせいただき、受
>> 信されたメールを削除していただきますようお願い致します。
>> PLEASE READ:
>> The information contained in this e-mail is confidential and intended for
>> the named recipient(s) only.
>> If you are not an intended recipient of this e-mail, you are hereby
>> notified that any review, dissemination, distribution or duplication of
>> this message is strictly prohibited. If you have received this message in
>> error, please notify the sender immediately and delete your copy from your
>> system.
>>
>>
>> __**_
>> specs mailing list
>> sp...@lists.openid.net
>> http://lists.openid.net/**mailman/listinfo/openid-specs<http://lists.openid.net/mailman/listinfo/openid-specs>
>>
>
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Vote for Second OpenID Connect Implementer’s Drafts is Open

[Nat Sakimura]

Hi Everybody:

Voting has opened on the Second OpenID Connect Implementer's Draft.
If you are an OpenID Foundation member, please register your vote before
2013-07-30.

To Vote, goto:
https://openid.net/foundation/members/polls/68


Description:
The OpenID Connect Working Group recommends approval of the following
specifications as OpenID Implementer’s Drafts:

  • Basic Client Profile – Simple, self-contained profile for a Web-based
Relying Parties using the OAuth code flow.
  • Implicit Client Profile – Simple, self-contained profile for a
Web-based Relying Parties using the OAuth implicit flow.
  • Messages – Defines the messages that are used by OpenID Connect.
  • Standard – Defines an HTTP binding for the Messages, for both Relying
Parties and OpenID Providers.
  • Discovery – Defines how Relying Parties dynamically discover
information about OpenID Providers.
  • Dynamic Registration – Defines how Relying Parties dynamically register
with OpenID Providers.
  • Session Management – Defines how to manage OpenID Connect sessions,
including logout functionality.
  • Multiple Response Type Encoding – Registers OAuth 2.0 “response_type”
values used by OpenID Connect.

An Implementer’s Draft is a stable version of a specification providing
intellectual property protections to implementers of the specification.

The specifications are posted at these locations:
  • http://openid.net/specs/openid-connect-basic-1_0-28.html
  • http://openid.net/specs/openid-connect-implicit-1_0-11.html
  • http://openid.net/specs/openid-connect-messages-1_0-20.html
  • http://openid.net/specs/openid-connect-standard-1_0-21.html
  • http://openid.net/specs/openid-connect-discovery-1_0-17.html
  • http://openid.net/specs/openid-connect-registration-1_0-19.html
  • http://openid.net/specs/openid-connect-session-1_0-15.html
  • http://openid.net/specs/oauth-v2-multiple-response-types-1_0-08.html

A description of OpenID Connect can be found at http://openid.net/connect/.
The working group page ishttp://openid.net/wg/connect/.  The original
announcement of these proposed Implementer’s Drafts and of this vote can be
found at
http://openid.net/2013/06/07/review-of-proposed-openid-connect-implementers-drafts/
.


Available Choices:
* Approve
* Object
* Abstain

Thank you for your participation!

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [community] from W3C….Fwd: Proposal: "User" header field

[Nat Sakimura]

case is the same as "From" in fact, my ideal would have been
> just to loosen the scope of "From" but there was pushback from the IETF on
> this, with the suggestion to think of another header name.
> >>>
> >>> In particular, one thing we are working on in the Read Write Web
> Community Group is fine grained access control for writing or appending a
> file.  It's helpful to know who is trying to make a change before returning
> e.g. SUCCESS or FORBIDDEN response codes.
> >>>
> >>>
> >>> On a more specific level, this looks like "On-behalf-of" - a more
> indicative name than "user" for the seemingly potential usage (this request
> is performed on behalf of the user X)?
> >>>
> >>> I'd be very happy to reuse something existing, so long as it allowed
> URLs and email address too.  If I'm correct, On-behalf-of is email specific?
> >>>
> >>>
> >>> I'm not sure why OpenIDs couldn't appear in this header, FWIW. The
> recipient could run OpenID protocol with the client, regarding the
> identifier sent in the header. That would allow "verification" of the
> OpenID to occur, wouldn't it?
> >>>
> >>> Well I hadnt thought of that, but yes that could work quite well!  One
> of the perceived issues with OpenID as a URL (dating back as far as Yadis)
> was that the UX for typing in an HTTP URL lead to a loss of conversions.
>  If this could be done by the software and may save some typing, especially
> on mobile devices.  The same technique could be used with PKI if the URL
> contained a public key and the (rich) client could store the private key.
>  I think that will become a more valuable use case next year when crypto on
> the browser becomes a REC
> >>>
> >>>
> >>> John
> >>>
> >>> On Jul 17, 2013, at 7:41 PM, Melvin Carvalho 
> wrote:
> >>>
> >>> >
> >>> >
> >>> >
> >>> > On 18 July 2013 01:06, Nat Sakimura  wrote:
> >>> > Hi.
> >>> >
> >>> > I am forwarding the mail in the identity commons list.
> >>> >
> >>> > Apparently, there is an initiative at W3C proposing a new "identity"
> header, which I believe is actually harmful for the general public. Simple
> web sites are going to take it as authenticated identity and thus will
> cause identity theft of their users.
> >>> >
> >>> > Their proposal is to include
> >>> >
> >>> >   User: http://this.is.the/user/identifier
> >>> >
> >>> > in the HTTP header.
> >>> >
> >>> > Could those of you active in W3C reach out to them?
> >>> >
> >>> > As I have written below, if it were to just include the IdP address
> as a hint, I am kind of fine.
> >>> >
> >>> > Thanks for sharing this.  Since this was my proposal, I hope I can
> shed a bit of light light.
> >>> >
> >>> > Firstly, it's not the W3C, simply a group of people brainstorming in
> the a W3C hosted forum (aka community groups).  The proposal has no
> official standing, but if there are no objections, the idea is to try and
> push the idea upstream.
> >>> >
> >>> > Yes, the idea is that it is just a hint.  Note the text:
> >>> >
> >>> > "The client SHOULD NOT send the User header field without the user's
> approval, as it might conflict with the user's privacy interests or their
> site's security policy. It is strongly recommended that the user be able to
> disable, enable, and modify the value of this field at any time prior to a
> request."
> >>> >
> >>> > We asked the IETF if we could use the "From" header for this, but
> the feedback is that "From" is restricted to email, and this would be
> difficult to change.  The suggestion was to come up with a new header.
>  Very happy to have feedback, I've followed IIW work for many years.
> >>> >
> >>> >
> >>> > Best,
> >>> >
> >>> > Nat
> >>> >
> >>> > -- Forwarded message --
> >>> > From: Kaliya "Identity Woman" 
> >>> > Date: 2013/7/18
> >>> > Subject: Re: [community] from W3C….Fwd: Proposal: "User" header field
> >>> > To: Nat Sakimura 
> >>> > Cc: "commun...@lists.idcommon

Re: [community] from W3C….Fwd: Proposal: "User" header field

[Nat Sakimura]

Thanks for reaching out and the clarification.

I gather that you envision some kind of user interface on the browser so
that the user can store the user identifier in the URI form (which happen
to be OpenID 1.0 concept, btw).

Then, the web sites asks for the header when they want, and the user
encounters a dialogue whether or not to give it.

Is that the use case?

IMHO, there are two problems with it.

1. Re: privacy: People will be trained to click Yes, turning the Internet
Dog into Pavlov's Dog.
2. Re: security: Web sites will make mistakes to assume that is an
authenticated identifier. It is not.
It is easy to spoof. It will cause user's accounts being hijacked, etc.
3. Re: fraud: Users has no protection layer between the malicious site and
the web browser.
It is a common attack by the fraudulent sites to ask for money when
they get hold of user's identifier.
In the IdP model, IdPs can block and filter the RP request for the user
identifier protecting the user.
It has been a big issue in Japan, at least, since Mobile browsers of
the feature phones actually
sent the user identifier as hint.

Even if we say "it is just a hint" in the specification, people will not
read it and make mistakes.
It is the duty of us protocol designers to consider these "human factors"
into account and consider the public safety issues.

I would probably be ok to send the IdP's address as a hint, as it cannot be
mistaken as a user identifier then by the sites. It poses less  privacy
issues as well, and users has more protection.

Best,

Nat


2013/7/18 Melvin Carvalho 

>
>
>
> On 18 July 2013 01:06, Nat Sakimura  wrote:
>
>> Hi.
>>
>> I am forwarding the mail in the identity commons list.
>>
>> Apparently, there is an initiative at W3C proposing a new "identity"
>> header, which I believe is actually harmful for the general public. Simple
>> web sites are going to take it as authenticated identity and thus will
>> cause identity theft of their users.
>>
>> Their proposal is to include
>>
>>   User: http://this.is.the/user/identifier
>>
>> in the HTTP header.
>>
>> Could those of you active in W3C reach out to them?
>>
>> As I have written below, if it were to just include the IdP address as a
>> hint, I am kind of fine.
>>
>
> Thanks for sharing this.  Since this was my proposal, I hope I can shed a
> bit of light light.
>
> Firstly, it's not the W3C, simply a group of people brainstorming in the a
> W3C hosted forum (aka community groups).  The proposal has no official
> standing, but if there are no objections, the idea is to try and push the
> idea upstream.
>
> Yes, the idea is that it is just a hint.  Note the text:
>
> "The client SHOULD NOT send the User header field without the user's
> approval, as it might conflict with the user's privacy interests or their
> site's security policy. It is strongly recommended that the user be able to
> disable, enable, and modify the value of this field at any time prior to a
> request."
>
> We asked the IETF if we could use the "From" header for this, but the
> feedback is that "From" is restricted to email, and this would be difficult
> to change.  The suggestion was to come up with a new header.  Very happy to
> have feedback, I've followed IIW work for many years.
>
>
>>
>> Best,
>>
>> Nat
>>
>> -- Forwarded message --
>> From: Kaliya "Identity Woman" 
>> Date: 2013/7/18
>> Subject: Re: [community] from W3C….Fwd: Proposal: "User" header field
>> To: Nat Sakimura 
>> Cc: "commun...@lists.idcommons.net" 
>>
>>
>> Yes Nat,  Thats sort of what I got from reading it.
>>
>> Who among us is very active in the W3C world?
>>
>> If no one should we be figuring out who should be?
>>
>> Should we write them a letter asking them to send "identitish" proposals
>> to IIW? or other forums for good input?
>>
>> Maybe we should write something that is like understanding identity
>> basics for technical specification folks across a range of standards bodies?
>>
>> - Kaliya
>>
>> On Jul 17, 2013, at 3:32 AM, Nat Sakimura wrote:
>>
>> Whoa, what's that?!
>>
>> That's not only useless but actually harmful.
>>
>> I can kind of see some utility in sending the IdP address, but not the
>> user.
>>
>> =nat via iPhone
>>
>> On Jul 16, 2013, at 7:39, "Kaliya \"Identity Woman\"" <
>> kaliya-li...@identitywoman.net> wrote:
>>
>> Hi folks,
>>

Fwd: [community] from W3C….Fwd: Proposal: "User" header field

[Nat Sakimura]

Hi.

I am forwarding the mail in the identity commons list.

Apparently, there is an initiative at W3C proposing a new "identity"
header, which I believe is actually harmful for the general public. Simple
web sites are going to take it as authenticated identity and thus will
cause identity theft of their users.

Their proposal is to include

  User: http://this.is.the/user/identifier

in the HTTP header.

Could those of you active in W3C reach out to them?

As I have written below, if it were to just include the IdP address as a
hint, I am kind of fine.

Best,

Nat

-- Forwarded message --
From: Kaliya "Identity Woman" 
Date: 2013/7/18
Subject: Re: [community] from W3C….Fwd: Proposal: "User" header field
To: Nat Sakimura 
Cc: "commun...@lists.idcommons.net" 


Yes Nat,  Thats sort of what I got from reading it.

Who among us is very active in the W3C world?

If no one should we be figuring out who should be?

Should we write them a letter asking them to send "identitish" proposals to
IIW? or other forums for good input?

Maybe we should write something that is like understanding identity basics
for technical specification folks across a range of standards bodies?

- Kaliya

On Jul 17, 2013, at 3:32 AM, Nat Sakimura wrote:

Whoa, what's that?!

That's not only useless but actually harmful.

I can kind of see some utility in sending the IdP address, but not the
user.

=nat via iPhone

On Jul 16, 2013, at 7:39, "Kaliya \"Identity Woman\"" <
kaliya-li...@identitywoman.net> wrote:

Hi folks,
 Apparently the W3C wants to send "user" names along in HTTP headers.
  I thought some folks who know about identity and how it does/could/should
work might be up for chiming in over there.
  It seems like Authentication of identity might be a good thing rather
then just assertion.
 - Kaliya


Begin forwarded message:

*From: *Christine


As you know, I'm a big proponent of open standards. For this reason I
monitor many groups. You might be interested in the W3C Read Write Web
community group: http://www.w3.org/community/rww/

I sent you a message a few weeks ago about Tabulator.

See below messages about User header field. If you are not already a
member, I recommend you join and contribute!

Christine


 Original Message   Subject: Re: Proposal: "User" header
field  Resent-Date: Sat, 13 Jul 2013 16:19:02 +  Resent-From:
public-...@w3.org  Date: Sat, 13 Jul 2013 12:08:37 -0400  From: Joe
   To: Melvin Carvalho
   CC: public-rww
 

Great job Melvin!

 Data.fm sends the User header already :)




On Jul 13, 2013, at 10:55 AM, Melvin Carvalho 
wrote:

  I would be nice to be able to identify a user in HTTP, especially with
read/write protocols and access control, it can be important to know who is
trying to change something.

There has been some discussion on whether the "From" header can be used to
identify a user in HTTP, and my from most people is that this would be a
good candidate to send a user, but for historical reasons it's limited to
email, and changing this would perhaps get some pushback from the IETF.

The suggestion has been to choose another header, so I thought that "User"
might be a good candidate, since we have User Agent arleady.

 Here's the proposed text:

[[
User

The User request-header field, if given, SHOULD contain an identifier for
the human user who controls the requesting user agent. The address SHOULD
be machine-usable, as defined by the "URI General Syntax" RFC 3986

   User   = "User" ":" URI

An example is:

   User: http://www.w3.org/People/Berners-Lee/card#i

This header field MAY be used for logging purposes and as a means for
identifying the source of invalid or unwanted requests. It SHOULD NOT be
used as an insecure form of access protection. The interpretation of this
field is that the request is being performed on behalf of the person given,
who accepts responsibility for the method performed. In particular, robot
agents SHOULD include this header so that the person responsible for
running the robot can be contacted if problems occur on the receiving end.

The client SHOULD NOT send the User header field without the user's
approval, as it might conflict with the user's privacy interests or their
site's security policy. It is strongly recommended that the user be able to
disable, enable, and modify the value of this field at any time prior to a
request.

]]

 Feedback welcome!






You received this message as a subscriber on the list:
commun...@lists.idcommons.net
To be removed from the list, send any message to:
community-unsubscr...@lists.idcommons.net

For all list information and functions, see:
 http://lists.idcommons.net/lists/info/community





-- 
Nat Sakimura (=nat)
Chairm

Re: [OIDFSC] Native application SSO Working Group

[Nat Sakimura]

r* beloved Tony was not part of the R&B group
> from Oakland, briefly popular in the 90s.
>
> https://en.wikipedia.org/wiki/Tony!_Toni!_Ton%C3%A9<https://en.wikipedia.org/wiki/Tony%21_Toni%21_Ton%C3%A9>
> !
>
> On 7/17/13 2:33 PM, Don Thibeau wrote:
>
> Paul 
>
>  
>
> I don't think "Tony Tony Tony"  is a good name for a working group :)
>
>  
>
> Don Thibeau
>
> The OpenID Foundation <http://openid.net>
>
>  
>
>  
>
>  
>
> On Jul 17, 2013, at 2:30 PM, Paul Madsen wrote:
>
>  
>
>  Tony Tony Tony, how I've missed our time together
>
> The WG's mandate is to profile OIDC to enable an SSO model for native
> mobile applications.
>
> Can you suggest a better (concise & memorable) descriptor for a mail list
> identifier?
>
> paul
>
> On 7/17/13 2:17 PM, Anthony Nadalin wrote:
>
> That’s a totally useless name 
>
>  
>
> *From:* openid-specs-boun...@lists.openid.net [
> mailto:openid-specs-boun...@lists.openid.net]
> *On Behalf Of *Paul Madsen
> *Sent:* Wednesday, July 17, 2013 10:59 AM
> *To:* Mike Jones
> *Cc:* John Bradley; sp...@openid.net; John Ehrig; Don Thibeau
> *Subject:* Re: [OIDFSC] Native application SSO Working Group
>
>  
>
> that list name is fine
>
> thanks
>
> On 7/17/13 1:51 PM, Mike Jones wrote:
>
> John, are you able to create the new mailing list at lists.openid.net or
> do we have to ask supp...@osuosl.org for the list creation?
>
>  
>
> Paul and other WG creators, what name do you want the list to have?
> openid-specs-native-sso?
>
>  
>
> -- Mike
>
>  
>
> *From:* Don Thibeau [mailto:d...@oidf.org ]
> *Sent:* Wednesday, July 17, 2013 5:03 AM
> *To:* Paul Madsen
> *Cc:* n-sakimura; John Ehrig; openid-specs@lists.openid.net; John
> Bradley; Mike Jones
> *Subject:* Re: [OIDFSC] Native application SSO Working Group
>
>  
>
> John Ehrig can set up the web site space and the online Docusign process
> for IPR collection.  If done right away it saves all concerned lots of time
> and hassle.
>
>  
>
>  
>
> Don Thibeau
>
> The OpenID Foundation <http://openid.net/>
>
>  
>
>  
>
>  
>
> On Jul 17, 2013, at 7:59 AM, Paul Madsen wrote:
>
>
>
> 
>
> Thanks Nat,
>
> Don, can you direct me to whomever I should work with on the WG list &
> page logistics?
>
> Paul
>
> On 7/16/13 6:08 AM, n-sakimura wrote:
>
> The WG formation is deemed to be approved per section 4.2 of the OpenID
> Process Document v.1.5 of 2009.
>
> A new mailing list should be established promptly per section 4.3 of the
> above document. Also, a WG web pages should be set up at openid.net. You
> should also ask the secretary of the foundation to announce the first
> meeting of the WG, in which scope approval and the chairs selection should
> be done.
>
> Note: the first meeting can only be done after the WG has collected the
> IPR agreement from the participants, so it may not be as quick as you may
> wish, but it has to be done. BTW, NRI's agreement is already in as we have
> a blanket agreement like Google.
>
> Nat
>
> (2013/07/15 14:56), Paul Madsen wrote:
>
> 
>
> Next steps?
>
> ---
> Paul Madsen
> Ping Identity
>
> Anthony Nadalin   wrote:
>
>
> 
>
> I believe if you dig you will see that there is potential for IPR from
> both Apple and Facebook.
>
> -Original Message-
> From: openid-specs-boun...@lists.openid.net [
> mailto:openid-specs-boun...@lists.openid.net]
> On Behalf Of n-sakimura
> Sent: Wednesday, July 3, 2013 10:20 PM
> To: openid-specs@lists.openid.net
> Subject: Re: [OIDFSC] Native application SSO Working Group
>
> Could you kindly spell it out?
>
>  From what I have been hearing, Facebook was just using fast application
> switch, which is nothing more than Self-issued thing that we have, and
> iOS's native login support given to facebook, twitter, and Weibo.
> Perhaps you are thinking of something else.
>
> Of course, I could be complete wrong. I should probably read
> https://developers.facebook.com/docs/howtos/ios-6/
> and
>
>
> http://developer.apple.com/library/ios/#documentation/Social/Reference/Social_Framework/_index.html#//apple_ref/doc/uid/TP40012233
>
> as well.
>
> Having said that, if Apple's interface is not open, perhaps it is a task
> for an i

Re: Native application SSO Working Group

[Nat Sakimura]

Yes. The law enforcement guy's use case was exactly that.
He wanted to generated ID Token and through it to the server to login to
the server and receive service.
His application was also location sensitive.


2013/7/3 Torsten Lodderstedt 

> Hi,
>
> I agree with Nat on this use case. Another one is that the app wants to
> use the id_token as credential on its "home" IDP (probably via JWT bearer
> token profile). This is more or less 3rd party login for apps.
>
> regards,
> Torsten.
>
>
>
> Nat Sakimura  schrieb:
>
>> Yes. If the app wants the identity information to evaluate its own access
>> control, then it would probably want to know about the user identity (i.e.,
>> set of attributes related to the entity), and id_token is the right thing.
>>
>> When I was talking to some law enforcement people in EU, they were
>> talking similar things. Right now, we do not have any location data defined
>> in the claims, but we may also want to do so in such cases.
>>
>> Nat
>>
>>
>> 2013/7/3 Paul Madsen 
>>
>>>  Hi Nat, the current AZA model does not preclude an access token being
>>> formatted as an id_token.
>>>
>>> I believe Torsten was conjecturing that there was potential value in an
>>> id_token being delivered to a native app in addition to an access token
>>> (whether formatted as id_token or not)
>>>
>>> Regards
>>>
>>> paul
>>>
>>>
>>> On 7/2/13 10:53 AM, Nat Sakimura wrote:
>>>
>>> I actually do see some utility in the access token in the format of ID
>>> Token.
>>> It can give appropriate audience restriction etc.
>>>
>>>
>>>  2013/7/2 Paul Madsen 
>>>
>>>>  Hi Torsten, the current model is that the Authorization Agent (AZA)
>>>> may itself obtain an id_token and use it to obtain an access token, but
>>>> that only access tokens would be 'handed over' by the AZA to its
>>>> constituent native apps.
>>>>
>>>> Are you proposing that there may be value in allowing the AZA to also
>>>> hand over id_tokens (suitably targeted) as well?
>>>>
>>>> paul
>>>>
>>>>   On 7/1/13 1:38 PM, Torsten Lodderstedt wrote:
>>>>
>>>>  Hi John,
>>>>
>>>> I interpreted the text of the charter the other way around, so a client
>>>> would be able to use an(y) id_token (as a credential) to obtain an access
>>>> token. I'm fine if the mechanism is intended to support id_token issuance.
>>>>
>>>> regards,
>>>> Torsten.
>>>>
>>>>  Am 01.07.2013 15:06, schrieb John Bradley:
>>>>
>>>> Hi Torsten,
>>>>
>>>>  In point 3 the charter talks about using id_tokens to get access
>>>> tokens.
>>>>
>>>>  So it is imagined that the mechanism would issue id_tokens likely
>>>> along the lines that Google is doing for the play store by having a 3rd
>>>> party as an audience and using "azp" to indicate the client the token was
>>>> issued to.   We don't want to be too specific on the solution in the
>>>> charter.
>>>>
>>>>  If you think something needs to be added let me know.
>>>>
>>>>  John B.
>>>>
>>>>   On 2013-07-01, at 2:17 AM, Torsten Lodderstedt <
>>>> tors...@lodderstedt.net> wrote:
>>>>
>>>> Hi,
>>>>
>>>> it would be great to have such a mechanism across platforms!
>>>>
>>>> I'm wondering whether the mechanism should issue id tokens as well.
>>>> Right now it seems to focus on access tokens.
>>>>
>>>> Regards,
>>>> Torsten.
>>>>
>>>>
>>>>
>>>> John Bradley  schrieb:
>>>>>
>>>>> The enclosed Work Group Charter is being sent to the Specs Council for 
>>>>> review in anticipation of chartering the Group.
>>>>>
>>>>> It is best have this activity under the foundation IPR as soon as 
>>>>> possible.
>>>>>
>>>>> Regards
>>>>> John B.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>>
>>>>> specs mailing 
>>>>> listspecs@lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>  ___
>>>> specs mailing 
>>>> listspecs@lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>>
>>>>
>>>> ___
>>>> specs mailing list
>>>> sp...@lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>>
>>>
>>>
>>>  --
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>>
>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Native application SSO Working Group

[Nat Sakimura]

Yes. If the app wants the identity information to evaluate its own access
control, then it would probably want to know about the user identity (i.e.,
set of attributes related to the entity), and id_token is the right thing.

When I was talking to some law enforcement people in EU, they were talking
similar things. Right now, we do not have any location data defined in the
claims, but we may also want to do so in such cases.

Nat


2013/7/3 Paul Madsen 

>  Hi Nat, the current AZA model does not preclude an access token being
> formatted as an id_token.
>
> I believe Torsten was conjecturing that there was potential value in an
> id_token being delivered to a native app in addition to an access token
> (whether formatted as id_token or not)
>
> Regards
>
> paul
>
>
> On 7/2/13 10:53 AM, Nat Sakimura wrote:
>
> I actually do see some utility in the access token in the format of ID
> Token.
> It can give appropriate audience restriction etc.
>
>
>  2013/7/2 Paul Madsen 
>
>>  Hi Torsten, the current model is that the Authorization Agent (AZA) may
>> itself obtain an id_token and use it to obtain an access token, but that
>> only access tokens would be 'handed over' by the AZA to its constituent
>> native apps.
>>
>> Are you proposing that there may be value in allowing the AZA to also
>> hand over id_tokens (suitably targeted) as well?
>>
>> paul
>>
>>   On 7/1/13 1:38 PM, Torsten Lodderstedt wrote:
>>
>>  Hi John,
>>
>> I interpreted the text of the charter the other way around, so a client
>> would be able to use an(y) id_token (as a credential) to obtain an access
>> token. I'm fine if the mechanism is intended to support id_token issuance.
>>
>> regards,
>> Torsten.
>>
>>  Am 01.07.2013 15:06, schrieb John Bradley:
>>
>> Hi Torsten,
>>
>>  In point 3 the charter talks about using id_tokens to get access tokens.
>>
>>  So it is imagined that the mechanism would issue id_tokens likely along
>> the lines that Google is doing for the play store by having a 3rd party as
>> an audience and using "azp" to indicate the client the token was issued to.
>>   We don't want to be too specific on the solution in the charter.
>>
>>  If you think something needs to be added let me know.
>>
>>  John B.
>>
>>   On 2013-07-01, at 2:17 AM, Torsten Lodderstedt 
>> wrote:
>>
>> Hi,
>>
>> it would be great to have such a mechanism across platforms!
>>
>> I'm wondering whether the mechanism should issue id tokens as well. Right
>> now it seems to focus on access tokens.
>>
>> Regards,
>> Torsten.
>>
>>
>>
>> John Bradley  schrieb:
>>>
>>> The enclosed Work Group Charter is being sent to the Specs Council for 
>>> review in anticipation of chartering the Group.
>>>
>>> It is best have this activity under the foundation IPR as soon as possible.
>>>
>>> Regards
>>> John B.
>>>
>>>
>>>
>>>
>>>  --
>>>
>>> specs mailing 
>>> listspecs@lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>>
>>
>>
>>
>>  ___
>> specs mailing 
>> listspecs@lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>>
>> ___
>> specs mailing list
>> sp...@lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>
>
>  --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Native application SSO Working Group

[Nat Sakimura]

I actually do see some utility in the access token in the format of ID
Token.
It can give appropriate audience restriction etc.


2013/7/2 Paul Madsen 

>  Hi Torsten, the current model is that the Authorization Agent (AZA) may
> itself obtain an id_token and use it to obtain an access token, but that
> only access tokens would be 'handed over' by the AZA to its constituent
> native apps.
>
> Are you proposing that there may be value in allowing the AZA to also hand
> over id_tokens (suitably targeted) as well?
>
> paul
>
>  On 7/1/13 1:38 PM, Torsten Lodderstedt wrote:
>
> Hi John,
>
> I interpreted the text of the charter the other way around, so a client
> would be able to use an(y) id_token (as a credential) to obtain an access
> token. I'm fine if the mechanism is intended to support id_token issuance.
>
> regards,
> Torsten.
>
>  Am 01.07.2013 15:06, schrieb John Bradley:
>
> Hi Torsten,
>
>  In point 3 the charter talks about using id_tokens to get access tokens.
>
>  So it is imagined that the mechanism would issue id_tokens likely along
> the lines that Google is doing for the play store by having a 3rd party as
> an audience and using "azp" to indicate the client the token was issued to.
>   We don't want to be too specific on the solution in the charter.
>
>  If you think something needs to be added let me know.
>
>  John B.
>
>   On 2013-07-01, at 2:17 AM, Torsten Lodderstedt 
> wrote:
>
> Hi,
>
> it would be great to have such a mechanism across platforms!
>
> I'm wondering whether the mechanism should issue id tokens as well. Right
> now it seems to focus on access tokens.
>
> Regards,
> Torsten.
>
>
>
> John Bradley  schrieb:
>>
>> The enclosed Work Group Charter is being sent to the Specs Council for 
>> review in anticipation of chartering the Group.
>>
>> It is best have this activity under the foundation IPR as soon as possible.
>>
>> Regards
>> John B.
>>
>>
>>
>>
>>  --
>>
>> specs mailing 
>> listspecs@lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>
>
>
> _______
> specs mailing 
> listspecs@lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs
>
>
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

ML setting modification

[Nat Sakimura]

Dear WG leaders:

I have modified the ML settings so that emails from unsubscribed
members get rejected.
This was to mitigate the high load of spam in some mailing lists.

If you have problems, please let me know.

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Backplane Protocol Working Group Charter Submission

[Nat Sakimura]

iewer?a=v&pid=forums&srcid=MTQ2NzA4MzgwMDk0MDY4NDM0MDABMTM2MTI2MTk1ODQ1OTQ4NDI5MTcBNEZCNDAxNUYuODAyMDUwNUBqYW5yYWluLmNvbQEyAQ&authuser=0>
>   (draft
> 13, June 2012, HTML)
>
> Backplane Exchange Specification 
> 2.0<http://backplane.wordpress.janrain.com/files/2012/05/backplane-2_0-draft12.pdf>
>  (draft 12, May 2012, HTML)
> Backplane Exchange Specification 
> 2.0<http://backplane.wordpress.janrain.com/files/2012/05/backplane-2_0-draft12.pdf>
>  (draft 10, March 2012, HTML)
> Backplane Exchange Specification 
> 2.0<http://backplanex.com/documentation/backplane-specification-2-0/> (draft 
> 07, January 2012, HTML)
>
> Version 1.0 (Currently in Production)
> Backplane Exchange Specification 
> 1.2<http://backplanex.com/documentation/backplane-specification-1-2/>(June 
> 2011, HTML)
> Backplane Exchange Specification 
> 1.1<http://backplanex.com/documentation/backplane-specification-1-1/>(June 
> 2011, HTML)
> Backplane Exchange Specification 
> 1.0<http://backplanex.com/documentation/backplane-specification-1-0>(November 
> 2010, HTML)
>
> *VI. Anticipated Audience*
>
> Interested parties would include:
>
>  ·   Website Operators that need to use third-party applications on
> their sites and want to improve usability and interoperability.
>
> ·   Relying Parties that are looking to distribute personalized
> services on other portals versus their own websites.
>
>
> A number of participating websites and vendors interested in Backplane
> Protocol and the advancement of the specifications are listed 
> here.<http://backplanex.com/showcase/>
>
> *VII. Language of business*
>
> English.
>
> *VIII. Method of work*
>
> Mailing list discussion.  Posting of intermediate drafts at
> http://backplanex.com or the OpenID Wiki.  Virtual conferencing on an
> ad-hoc basis.
>
> *IX. Basis for completion of the activity*
>
> When all items set forth in Section IV Scope have been addressed and
> agreed upon by members of the working group.
>
> *X. Initial Membership*
>
> Johnny Bufu, Janrain
> Greg Keegstra, Janrain
> Vidya Shivkumar, Janrain
> Tom Raney, Janrain
> Vlad Skvortsov, Echo
>
> Yuri Lukyanov, Echo
>
> Alexander Zhuravlev, Echo
>  Chris Saad, Echo
>
> *XI. Expected contribution*
>
> Draft: Backplane Exchange Specification 2.0 (draft 13)
> <https://docs.google.com/viewer?a=v&pid=forums&srcid=MTQ2NzA4MzgwMDk0MDY4NDM0MDABMTM2MTI2MTk1ODQ1OTQ4NDI5MTcBNEZCNDAxNUYuODAyMDUwNUBqYW5yYWluLmNvbQEyAQ&authuser=0>
>
>
>
>
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Implementer's Drafts posted with -ID1 version designations

[Nat Sakimura]

 version designations*
> ***
>
> ** **
>
> Gee, guys… I think something has gone terribly wrong here.  I was really
> excited about OpenID, believing it was a very important technology.
> Further, OpenID was fairly simple.  One part was complex: the client code
> for the RP had to deal with querying the user’s ID, looking for a Yadis
> file, and possibly digging through an HTML document – all in an effort to
> find the URI for the user’s OP.  The OP code, on the other hand, is fairly
> trivial.
>
> ** **
>
> OpenID 2.0 could have been simplified easily be removing the requirement
> for processing a Yadis file and HTML document and replacing that with a
> simple Link header in HTTP.  One could also use RFC 6415 (Host-Meta) to
> make it simple to advertise one’s OpenID ID (a “challenge” for the average
> person to use) and even the OP URI (though perhaps not so beneficial).
>
> ** **
>
> I wanted to get engaged in the work, but getting Cisco to sign agreements,
> especially when this was not my core job function, was a bit of a
> challenge.  So, the work proceeded without me.  It’s unfortunate, because
> my initial reaction to what I’ve seen is ... what happened?!?!
>
> ** **
>
> OpenID Connect was supposed to be simple.  That was one of the claim made
> when it was introduced.  Looking at these drafts, I’d argue that “simple”
> has been thrown out the window, in spite of the claim “simple” in the
> abstract of these documents.  Perhaps it’s just a false first impression,
> but these documents certainly appear to introduce a lot of procedure and
> make reference to number of required specifications that are not listed in
> the list below.
>
> ** **
>
> Do you really want to go down this path?  I would still be open to a
> simplification of OpenID 2.0 to remove the pain points.
>
> ** **
>
> Paul
>
> ** **
>
> *From:* openid-specs-boun...@lists.openid.net
> [mailto:openid-specs-boun...@lists.openid.net] *On Behalf Of *Mike Jones
> *Sent:* Monday, February 27, 2012 8:36 PM
> *To:* sp...@openid.net
> *Cc:* bo...@openid.net
> *Subject:* Implementer’s Drafts posted with -ID1 version designations
>
> ** **
>
> The approved Implementer’s Drafts are now also posted at these locations:*
> ***
>
> **· **http://openid.net/specs/openid-connect-basic-1_0-ID1.html***
> *
>
> **· **
> http://openid.net/specs/openid-connect-discovery-1_0-ID1.html
>
> **· **
> http://openid.net/specs/openid-connect-registration-1_0-ID1.html
>
> **· **http://openid.net/specs/openid-connect-messages-1_0-ID1.html
> 
>
> **· **http://openid.net/specs/openid-connect-standard-1_0-ID1.html
> 
>
> **· **
> http://openid.net/specs/oauth-v2-multiple-response-types-1_0-ID1.html
>
> ** **
>
> The original versions with numeric version designations remain in place.**
> **
>
> ** **
>
> -- Mike
>
> ** **
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

OpenID Connect Implementer’s Drafts Approved

[Nat Sakimura]

Dear OpenID Fans:

The OpenID membership has approved the following specifications as OpenID
Implementer’s Drafts in the vote held from February 7th to 15th,
2012<https://openid.net/foundation/members/polls/62>
 at https://openid.net/foundation/members/polls/62:

• Basic Client Profile – Simple self-contained specification for a
web-based Relying Party. (This spec contains a subset of the information in
Messages and Standard.)
• Discovery – Defines how user and provider endpoints can be dynamically
discovered.
• Dynamic Registration – Defines how clients can dynamically register with
OpenID Providers.
• Messages – Defines all the messages that are used in OpenID Connect.
(These messages are used by the Standard binding.)
• Standard – Complete HTTP binding of the Messages, for both Relying
Parties and OpenID Providers.
• Multiple Response Type Encoding – Registers OAuth 2.0 response_type
values used by OpenID Connect.

The voting results were:

   - Approve (86 votes)
   - Disapprove (1 vote)
   - Abstain (2 votes)

Total Votes: 89 (out of 363 members = 25% > 20% quorum requirement)

An Implementer’s Draft is a stable version of a specification providing
intellectual property protections to implementers of the specification.

The specifications are posted at these locations:

• http://openid.net/specs/openid-connect-basic-1_0-15.html
• http://openid.net/specs/openid-connect-discovery-1_0-07.html
• http://openid.net/specs/openid-connect-registration-1_0-08.html
• http://openid.net/specs/openid-connect-messages-1_0-07.html
• http://openid.net/specs/openid-connect-standard-1_0-07.html
• http://openid.net/specs/oauth-v2-multiple-response-types-1_0-03.html

A description of OpenID Connect can be found at http://openid.net/connect/.

The working group page is http://openid.net/wg/connect/.

Enjoy

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Working Group on Single Sign-Out?

[Nat Sakimura]

OpenID Connect WG is working on session management spec that deals with
single sign out as well.
It will be in the second batch of the deliverables, though.

=nat

On Sat, Dec 10, 2011 at 10:57 AM, Dave Tessman wrote:

> Is there a working group on Single Sign-Out?
> Is anyone thinking of starting one?
>
> Thanks,
>
> --Dave
>
> 
> Dave Tessman
> dtess...@zelestra.com
>
> *Zelestra*
> Software Architecture for the New Media™
> www.zelestra.com
>
>
>
>
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Mozilla BrowserID

[Nat Sakimura]

On Wed, Jul 20, 2011 at 1:05 PM, Manger, James H <
james.h.man...@team.telstra.com> wrote:

> >> As for one of the major advantages of BrowserID: it is a user-centric
> architecture unlike OpenID Connect.
>
> > Can you explain what you mean by "user-centric" in this context?
>
>
> With OAuth2 (and hence OpenID Connect, I assume) the RP needs to be
> registered with the IdP. It is not user-centric because the user cannot
> arbitrarily choose an IdP -- they can only choose an IdP with whom the RP is
> registered, which may well mean only one of a handful of major IdPs.
>

FYI, OpenID Connect supports dynamic registration of the client, though
whether the IdP supports the feature or not is an entirely different
question. Even in OpenID 2.0, there were IdPs who were white listing the
RPs.


>
> BrowserID is user-centric in that the RP can verify the signature of
> whichever email provider the user chooses. It doesn't rely on a prior
> agreements between the RP and IdP.
>
> --
> James Manger
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Mozilla BrowserID

[Nat Sakimura]

On Wed, Jul 20, 2011 at 3:01 PM, Henry Story wrote:

>
> On 20 Jul 2011, at 03:26, John Kemp wrote:
>
> > Hi Dick,
> >
> > On Jul 19, 2011, at 9:08 PM, Dick Hardt wrote:
> >
> >> As for one of the major advantages of BrowserID: it is a user-centric
> architecture unlike OpenID Connect.
> >
> > Can you explain what you mean by "user-centric" in this context? As far
> as I can tell, the "verified email" protocol (
> https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest) in use
> for BrowserID requires that the email provider generates a certificate
> verifying the email address, to the browser - I'm not sure how that is more
> user-centric than OpenID Connect... The default (canonical?) verifier is
> currently browserid.org, but I'd imagine that they expect that FB et al
> will verify the email addresses of their users and essentially produce
> identity assertions for their users, albeit in this browser-mediated
> manner... doesn't seem too different from what your Sxipper plugin or
> Infocards were trying to do with OpenID really...
>
> If you want a user centric protocol that works now - and with 10 years old
> browsers even - then you may want to try
> WebId http://webid.info/ - That was inspired by OpenID. It uses an http(s)
> url, but the user never sees it. It does not require control of an e-mail
> server to get one, so it is much more friendly to social networking
> services, and many other services that don't control the e-mail.
>
> It requires TLS Client certificates as of now.
>
> I have argued that if BrowserID does their thing right WebID authentication
> could also work with their JSON certificates, giving them RESTful attribute
> exchange too. By the way OpenId could also have RESTful attribute exchange.
>
>
> http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid/5424
>
> What OpenID showed is that users don't like to type a http URL in their
> box. I'd go even further: it is better not to have to type anything, but
> just click. BrowserId does that but for some reason has a fixation on not
> distinguishing between the  identifier that the user *sees* and the
> identifier used by the protocol.
>

I agree. If this "fixation" is removed, things gets much more palatable for
many people.


>
> So if we were all a bit flexible we could all work with web architecture
> and together.
>

+1


>
> Henry
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Mozilla BrowserID

[Nat Sakimura]

Minimum feature for IdP is to implement User Authorization Endpoint, Token
Endpoint, Introspection Endpoint.
UserInfo Endpoint and Session Endpoint is optional, though I really would
love to make UserInfo Endpoint a MUST.

These will be captured in the forthcoming document reorganization, so that
basic Connect spec will have those MUST endpoint only.

=nat

On Wed, Jul 20, 2011 at 1:45 AM, Johannes Ernst  wrote:

> > On Jul 19, 2011, at 9:01, Allen Tom wrote:
> >
> >> I think the market has shown that an URL-based identity system without
> any additional attributes (basic profile info, email address) or services
> (the ability to send notifications to the user) is not really a viable
> product, since the RP might as well have the user register a local account.
>
> I'd love to see the minimum viable list of features for an internet
> identity system now in 2011, and get some agreement on those. Arguably one
> of the failures of OpenID 2 has been that there was never any agreement on
> those, so everybody implemented a different subset.
>
> I realize I have a hard time commenting on the Connect work until it is
> clear what this minimum set of features is supposed to be. Perhaps that is
> documented somewhere and I just haven't seen it?
>
> Cheers,
>
>
>
> Johannes.
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Mozilla BrowserID

[Nat Sakimura]

Relying party using somebody's email address as login name and site specific
password was screwed today as you say.
We should fix the problem.

Email providers can actually distinguish between the old user and new user,
and password reset by email does not cross the old and new accounts so they
are not plagued by this problem. They should help the situation. One idea
for BrowserID is for the email provider to issue a certificate that includes
a canonical identifier of the user. Then, relying parties can use that as
the identifier and email as an attribute. In OpenID term, email is the user
supplied identifier and the unique string is the canonical identifier.

=nat

On Tue, Jul 19, 2011 at 2:14 PM, Allen Tom  wrote:

> Email address recycling is an important issue, but since the status quo
> (password reset via email) doesn't address the recycling issue, perhaps it's
> not necessary to solve it.
>
> It is important that RPs allow users to change their email address to
> prevent their RP account from being taken over if they lose the email
> address that they used to create the account. Perhaps that's good enough?
>
> Allen
>
>
> On Mon, Jul 18, 2011 at 10:02 PM, Nat Sakimura  wrote:
>
>> One of my concern around BrowserID is that it does not seem to take care
>> of the email address recycling.
>> Email address verification "certificate" may be short lived but it does
>> not solve the impersonation problem at all.
>> There has to be some ways of canonicalizing email address into a
>> non-re-assignable identifier.
>> Otherwise we are screwed and BrowserID spec does not yet provide the
>> solution.
>>
>> As a conceptual solution, BrowserID is interesting if the browsers
>> implements it and if we can get rid of BrowserID.org.
>> I would like to see more work towards. it.
>>
>> =nat
>>
>> On Tue, Jul 19, 2011 at 1:05 PM, Allen Tom wrote:
>>
>>> Yeah, I totally agree - I was referring to a hypothetical protocol that's
>>> similar to OpenID Connect, but uses email addresses as the true identifier.
>>>
>>> I don't see how BrowserID would be better than a version of OpenID
>>> Connect that only uses email addresses as the one true identifier.
>>>
>>> Allen
>>>
>>>
>>>
>>> On Mon, Jul 18, 2011 at 8:51 PM, Phillip Hallam-Baker 
>>> wrote:
>>>
>>>> There is an advantage to throwing out the bad identifiers, It allows the
>>>> user interface to be made a lot simpler as anything not an email address is
>>>> wrong.
>>>>
>>>> No URLs, no XRIs.
>>>>
>>>>
>>>> As for what to do if the email provider does not provide BrowserID, I
>>>> don't think it is a problem, I would probably separate the accounts in any
>>>> case.
>>>>
>>>>
>>> ___
>>> specs mailing list
>>> sp...@lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Mozilla BrowserID

[Nat Sakimura]

One of my concern around BrowserID is that it does not seem to take care of
the email address recycling.
Email address verification "certificate" may be short lived but it does not
solve the impersonation problem at all.
There has to be some ways of canonicalizing email address into a
non-re-assignable identifier.
Otherwise we are screwed and BrowserID spec does not yet provide the
solution.

As a conceptual solution, BrowserID is interesting if the browsers
implements it and if we can get rid of BrowserID.org.
I would like to see more work towards. it.

=nat

On Tue, Jul 19, 2011 at 1:05 PM, Allen Tom  wrote:

> Yeah, I totally agree - I was referring to a hypothetical protocol that's
> similar to OpenID Connect, but uses email addresses as the true identifier.
>
> I don't see how BrowserID would be better than a version of OpenID Connect
> that only uses email addresses as the one true identifier.
>
> Allen
>
>
>
> On Mon, Jul 18, 2011 at 8:51 PM, Phillip Hallam-Baker wrote:
>
>> There is an advantage to throwing out the bad identifiers, It allows the
>> user interface to be made a lot simpler as anything not an email address is
>> wrong.
>>
>> No URLs, no XRIs.
>>
>>
>> As for what to do if the email provider does not provide BrowserID, I
>> don't think it is a problem, I would probably separate the accounts in any
>> case.
>>
>>
> _______
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Mozilla BrowserID

[Nat Sakimura]

This is a good article, though I can cone up with a few more concerns.

"What are the downsides of BrowserID compared to OpenID/OAuth/Facebook? 6
useful questions that need answers.  http://j.mp/rcRC5h #browserid"

=nat via iPhone

On 2011/07/17, at 8:44, John Bradley  wrote:

I posted this to the specs-ab list earlier today.

Links for those that haven't looked yet.


https://browserid.org/

http://arstechnica.com/web/news/2011/07/mozillas-browserid-aims-to-simplify-authentication-on-the-web.ars


They are using asymmetrically signed JWT with an introspection endpoint.

There are limitations on attributes, identifiers and other serious issues
with what Mozzila is proposing.

Though it is relatively close to what Nat and I were thinking with
asymmetrically signed id_tokens, and a introspection endpoint.

In some ways our flow would be simpler if the id_tokens were always
asymmetrically signed and anyone not supporting that uses the introspection
endpoint, as they propose.

If the RP doesn't understand asymmetric signatures it just throws to the
introspection endpoint.
The big advantage is for smart clients.  They would not need to manage
shared secrets to validate tokens.

For a smart client I suppose that you could let it generate it's own access
tokens if those access tokens are JWT and they wrap a JWT containing the
client's public key and some scope constraints etc.   In principal that
could lower the IdP's authorization load.  It could also be a way to prevent
the IdP from knowing who the RP is in the simple SSO case.

If the browser supports asymmetric keys securely (they are using html5 local
storage keyed to a trusted domain) you could have the smart client provide
it's public key to the OP and have a assertion without an audience generated
and signed.   The client would then over-sign with an audience.  (some
potential size issues with double base46 encoding)

Just some things to think about.

John B.


On 2011-07-16, at 9:25 AM, David Recordon wrote:

Thoughts?

http://identity.mozilla.com/post/7669886219/how-browserid-differs-from-openid
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs


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

Re: URL redirection truncation problems

[Nat Sakimura]

On Tue, Dec 7, 2010 at 7:08 PM, Manuel Lemos  wrote:

> Hello,
>
> on 12/06/2010 10:59 PM Breno de Medeiros said the following:
>
>
>>>  - OpenID might define an 'artifact'-type workflow, as for instance,
>> the one proposed by the Artifact Binding WG, and shorten URLs of both
>> requests and responses to below 400 characters.
>>
>
> I am not sure what this means. Does it mean that is there already anything
> able to make redirect URLs shorter or it maybe something that future specs
> may support?
>
>
Next version of OpenID that is coming out in about a month actually does
it.


>
> --
>
> Regards,
> Manuel Lemos
>
> JS Classes - Free ready to use OOP components written in JavaScript
> http://www.jsclasses.org/
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: URL redirection truncation problems

[Nat Sakimura]

Hi Manuel,

FYI, your human friendly version of the Artifact Binding Spec proposal is
https://openid4.us/specs/ab/ .
It will change a few things before going to be final:

1. Change the signature to JWT that is supposed to come out this week or
so.
2. Split the spec into the core, binding, and profiles so that it will share
the same core as Connect.

Nat Sakimura

P.S. Actual spec archive is at http://bitbucket.org/openid/ab/

On Tue, Dec 7, 2010 at 9:59 AM, Breno de Medeiros  wrote:

> On Mon, Dec 6, 2010 at 16:41, Manuel Lemos  wrote:
> > Hello,
> >
> > I have developed my implementation of OpenID (consumer and provider). In
> > general works well and it has been used in sites use that authenticate
> > hundreds of thousands of users.
> >
> > The problem is that once in a while I get warnings from my system
> regarding
> > missing required attributes or invalided signatures.
> >
> > Looking closer at the problem I realized that in some cases the OpenID
> > provider redirects the users back to the consumer sites but the user
> > browsers are truncating URLs apparently at 400 characters.
>
> This could happen in some mobile devices.
>
> There are, AFAIK, only a few approaches to address this problem.
>
> - Choose to not support such user agents.
>
> - Providers might add detection for the problematic user-agents and
> change their handling to use a POST redirect. But keep in mind that
> this fix still is short of ideal:
> -- Sometimes these devices also not support javascript, in which case
> POST redirects require an additional confirmation dialog.
> -- POST redirect from https to http result in scary warning dialogs in
> some browsers. Avoiding this warning requires providers to invent some
> proprietary redirect with short URLs from the https location to an
> http location and start the POST operation from the http location. A
> better solution would be for RPs to implement SSL return_to URLs, but
> this has not been often done.
>
> - OpenID might define an 'artifact'-type workflow, as for instance,
> the one proposed by the Artifact Binding WG, and shorten URLs of both
> requests and responses to below 400 characters.
>
> >
> > Anybody experienced this problem?
> >
> > Admittedly I may have missed something in the spec documents, but is
> there
> > anything in the specs that provides a solution to avoid redirecting
> browsers
> > to such long URLs?
> >
> > --
> >
> > Regards,
> > Manuel Lemos
> >
> > JS Classes - Free ready to use OOP components written in JavaScript
> > http://www.jsclasses.org/
> > ___
> > specs mailing list
> > sp...@lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs
> >
>
>
>
> --
> --Breno
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: This is probably a good time to start talking about standard URI scheme

[Nat Sakimura]

Actually, I should have written as:

///#

but that is a minor issue, I think. (An extra "/" is there, which is kind of
important when we think of the server implementations.)

So, what would be the process to formalize it?
Do we just announce it as the specs council or something?

=nat

On Wed, Nov 17, 2010 at 11:07 PM, John Bradley  wrote:

> I think that works.
>
> It is always nice to have them dereference-able.
>
> The fragment allows for a single document.
>
> John B.
>
> On 2010-11-17, at 5:23 AM, Nat Sakimura wrote:
>
> Actually,
>
>  //#
>
> is quite nice in the sense that it should jump to the location in the spec
> document that describes the feature.
>
> =nat
>
> On Wed, Nov 17, 2010 at 5:12 PM, David Recordon wrote:
>
>> Sure, seems sane. As John points out some specs may define multiple URLs
>> in which case the format of /// seems
>> reasonable.
>>
>>
>> On Tue, Nov 16, 2010 at 2:44 PM, John Bradley  wrote:
>>
>>> We also have URI in use like http://specs.openid.net/auth/2.0/serveretc.
>>>
>>> I agree with managing the namespace for each spec in a more consistent
>>> way.
>>>
>>> John B.
>>>
>>>
>>> On 2010-11-16, at 2:19 AM, Nat Sakimura wrote:
>>>
>>>  I have been pitching this to some folks for sometime, but I think we
>>> should standardize on the URI scheme for each specifications. Chris also had
>>> the same message.
>>>
>>> Currently, the Authn 2.0 uses http://specs.openid.net/auth/2.0 as ns and
>>> spec is
>>> stored at http://openid.net/specs/openid-authentication-2_0.html
>>>
>>> AX1.0 uses http://openid.net/srv/ax/1.0 as ns and spec is
>>> stored at http://openid.net/specs/openid-attribute-exchange-1_0.html
>>>
>>> etc.
>>>
>>> I can point out two issues.
>>>
>>> (1) ns and spec location mismatch
>>> (2) seemingly random ns
>>>
>>> For the specs to come, I would like to propose the following scheme.
>>>
>>> http://openid.net/specs///
>>>
>>> For example, if it were applied to Auth 2.0,
>>>
>>> http://openid.net/specs/auth/2.0/
>>>
>>> Note the trailing slash.
>>>
>>> Other examples:
>>>
>>> http://openid.net/specs/ab/1.0/
>>> http://openid.net/specs/jwt/1.0/
>>> http://openid.net/specs/pape/1.1/
>>>
>>> etc.
>>>
>>> Cheers,
>>>
>>> Nat Sakimura
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  Original Message   Subject: SubVersion projects on
>>> svn.openid.net and file access on openid.net host  Date: Tue, 16 Nov
>>> 2010 01:18:35 +  From: Mike Jones 
>>>   To:
>>> supp...@osuosl.orgCC: John
>>> Bradley  , Nat Sakimura
>>>  , "Don Thibeau"
>>>  , John Ehrig 
>>> 
>>>
>>> Dear OSL folks,
>>>
>>> Can you please create these three new specification subtrees on 
>>> svn.openid.net:
>>> specifications/artifact_binding/1.0
>>> specifications/json_web_token/1.0
>>> specifications/oauth/2.0
>>> These people should have write access to the first two repositories:
>>> Mike Jones 
>>> m...@microsoft.com<mailto:m...@microsoft.com> 
>>> John Bradley  
>>> ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com> 
>>> Nat Sakimura 
>>> n-sakim...@nri.co.jp<mailto:n-sakim...@nri.co.jp> 
>>> Only I should have write access to the third one (oauth/2.0).
>>>
>>> Also, sometime since I was last working on the Provider Authentication 
>>> Policy Extension (PAPE) specification, my password or account on the host  
>>> openid.net was reset.  My userid there is "mbj".  Can you please reset my 
>>> password and call me at (425) 985-8916 to tell me the new one.  I need to 
>>> be able to log in to write content to the http://openid.net/specs/ 
>>> directory, which when I last did it was at the location 
>>> /var/www/openid.net/docs/specs.
>>>
>>> Thanks a bunch!
>>>
>>> -- Mike
>>>
>>> OAuth 2.0 
>>> Bearer Token spec editor
>>> JSON Web 
>>> Token spec editor
>>> OpenID 
>>> Artifact Binding committee member
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> specs mailing list
>>> sp...@lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>>
>>
>> ___
>> specs mailing list
>> sp...@lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
>  ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: This is probably a good time to start talking about standard URI scheme

[Nat Sakimura]

Actually,

 //#

is quite nice in the sense that it should jump to the location in the spec
document that describes the feature.

=nat

On Wed, Nov 17, 2010 at 5:12 PM, David Recordon  wrote:

> Sure, seems sane. As John points out some specs may define multiple URLs in
> which case the format of /// seems
> reasonable.
>
>
> On Tue, Nov 16, 2010 at 2:44 PM, John Bradley  wrote:
>
>> We also have URI in use like http://specs.openid.net/auth/2.0/server etc.
>>
>> I agree with managing the namespace for each spec in a more consistent
>> way.
>>
>> John B.
>>
>>
>> On 2010-11-16, at 2:19 AM, Nat Sakimura wrote:
>>
>>  I have been pitching this to some folks for sometime, but I think we
>> should standardize on the URI scheme for each specifications. Chris also had
>> the same message.
>>
>> Currently, the Authn 2.0 uses http://specs.openid.net/auth/2.0 as ns and
>> spec is
>> stored at http://openid.net/specs/openid-authentication-2_0.html
>>
>> AX1.0 uses http://openid.net/srv/ax/1.0 as ns and spec is
>> stored at http://openid.net/specs/openid-attribute-exchange-1_0.html
>>
>> etc.
>>
>> I can point out two issues.
>>
>> (1) ns and spec location mismatch
>> (2) seemingly random ns
>>
>> For the specs to come, I would like to propose the following scheme.
>>
>> http://openid.net/specs///
>>
>> For example, if it were applied to Auth 2.0,
>>
>> http://openid.net/specs/auth/2.0/
>>
>> Note the trailing slash.
>>
>> Other examples:
>>
>> http://openid.net/specs/ab/1.0/
>> http://openid.net/specs/jwt/1.0/
>> http://openid.net/specs/pape/1.1/
>>
>> etc.
>>
>> Cheers,
>>
>> Nat Sakimura
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  Original Message   Subject: SubVersion projects on
>> svn.openid.net and file access on openid.net host  Date: Tue, 16 Nov 2010
>> 01:18:35 +  From: Mike Jones 
>>   To:
>> supp...@osuosl.orgCC: John
>> Bradley  , Nat Sakimura
>>  , "Don Thibeau"
>>  , John Ehrig 
>> 
>>
>> Dear OSL folks,
>>
>> Can you please create these three new specification subtrees on 
>> svn.openid.net:
>> specifications/artifact_binding/1.0
>> specifications/json_web_token/1.0
>> specifications/oauth/2.0
>> These people should have write access to the first two repositories:
>> Mike Jones 
>> m...@microsoft.com<mailto:m...@microsoft.com> 
>> John Bradley  
>> ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com> 
>> Nat Sakimura 
>> n-sakim...@nri.co.jp<mailto:n-sakim...@nri.co.jp> 
>> Only I should have write access to the third one (oauth/2.0).
>>
>> Also, sometime since I was last working on the Provider Authentication 
>> Policy Extension (PAPE) specification, my password or account on the host  
>> openid.net was reset.  My userid there is "mbj".  Can you please reset my 
>> password and call me at (425) 985-8916 to tell me the new one.  I need to be 
>> able to log in to write content to the http://openid.net/specs/ directory, 
>> which when I last did it was at the location /var/www/openid.net/docs/specs.
>>
>> Thanks a bunch!
>>
>> -- Mike
>>
>>         OAuth 2.0 
>> Bearer Token spec editor
>> JSON Web 
>> Token spec editor
>> OpenID 
>> Artifact Binding committee member
>>
>>
>>
>>
>>
>> ___
>> specs mailing list
>> sp...@lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

This is probably a good time to start talking about standard URI scheme

[Nat Sakimura]

I have been pitching this to some folks for sometime, but I think we 
should standardize on the URI scheme for each specifications. Chris also 
had the same message.


Currently, the Authn 2.0 uses http://specs.openid.net/auth/2.0 as ns and 
spec is

stored at http://openid.net/specs/openid-authentication-2_0.html

AX1.0 uses http://openid.net/srv/ax/1.0 as ns and spec is
stored at http://openid.net/specs/openid-attribute-exchange-1_0.html

etc.

I can point out two issues.

(1) ns and spec location mismatch
(2) seemingly random ns

For the specs to come, I would like to propose the following scheme.

http://openid.net/specs///

For example, if it were applied to Auth 2.0,

http://openid.net/specs/auth/2.0/

Note the trailing slash.

Other examples:

http://openid.net/specs/ab/1.0/
http://openid.net/specs/jwt/1.0/
http://openid.net/specs/pape/1.1/

etc.

Cheers,

Nat Sakimura












 Original Message 
Subject: 	SubVersion projects on svn.openid.net and file access on 
openid.net host

Date:   Tue, 16 Nov 2010 01:18:35 +
From:   Mike Jones 
To: supp...@osuosl.org 
CC: 	John Bradley , Nat Sakimura 
, "Don Thibeau" , John Ehrig 





Dear OSL folks,

Can you please create these three new specification subtrees on svn.openid.net:
specifications/artifact_binding/1.0
specifications/json_web_token/1.0
specifications/oauth/2.0
These people should have write access to the first two repositories:
Mike Jones m...@microsoft.com<mailto:m...@microsoft.com>
John Bradley  ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>
    Nat Sakimura 
n-sakim...@nri.co.jp<mailto:n-sakim...@nri.co.jp>
Only I should have write access to the third one (oauth/2.0).

Also, sometime since I was last working on the Provider Authentication Policy Extension 
(PAPE) specification, my password or account on the host  openid.net was reset.  My 
userid there is "mbj".  Can you please reset my password and call me at (425) 
985-8916 to tell me the new one.  I need to be able to log in to write content to the 
http://openid.net/specs/ directory, which when I last did it was at the location 
/var/www/openid.net/docs/specs.

Thanks a bunch!

-- Mike

OAuth 2.0 
Bearer Token spec editor
JSON Web Token 
spec editor
OpenID Artifact 
Binding committee member



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

Re: Clarification

[Nat Sakimura]

I am hoping to do the signature at the beginning since it affects everything
(AB, Connect, OAuth itself, etc.)

It is also kind of unfortunate that the Connect "spec bashing" last night
was not organized as an appropriately announced WG event, informal or
formal. If it were, I could have joined as well as I was in Palo Alto.

=nat

On Mon, Nov 1, 2010 at 9:57 PM, John Bradley  wrote:

> David
>
> For clarification.
>
> Is thais a openID tech summit where work from the openID WG such as:
> Connect (Breno's contribution from Oct 22)
> OpenID Artifact binding (Spec and token proposals)
> OpenID Contract exchange
>
> Will be the agenda topics?
>
> Or is this to discuss the Connect work from last night that is not part of
> a WG.
>
> Other people are asking me this question.
>
> If facebook is setting the agenda that is fine with me, I would just like
> to be prepared. It's a long way for me to come so I would like to make some
> progress.
>
> John B.
>
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Connect WG?

[Nat Sakimura]

Hi.

Is the Connect WG starting?
I see no message in the archive. :
http://lists.openid.net/pipermail/openid-specs-connect/

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Requirements discussion of OpenID Future

[Nat Sakimura]

; Subject: Requirements discussion of OpenID Future
>>
>> Hi All,
>>
>> There¹s been a lot of discussion the past few weeks around specific 
>> technical proposals focused on moving OpenID forward. We wanted to take a 
>> step back and make sure that we understand the problems that there are broad 
>> consensus around solving over the next six to nine months. While there has 
>> also been some discussion around use cases and charters, there hasn¹t yet 
>> been broad consensus.
>>
>> Today Yahoo!, Google, and Facebook met with some of the authors of Artifact 
>> Binding, the OpenID Connect proposal, and OAuth 2.0 to discuss our specific 
>> future requirements.  We put together a summary document of 20+ items that 
>> we would like to see and wanted to start a discussion around them.  Today 
>> helped to verify our instinct that we could achieve these OpenID goals by 
>> layering features on top of OAuth 2.0 while specifically maintaining the 
>> decentralized nature of OpenID.
>>
>> After this discussion it seems that the Connect work group charter can 
>> encompass this work and thus provides a mailing list and IPR policy to work 
>> on these items. Facebook, Google, and Yahoo! expect to be able to sign the 
>> contributor agreements for the OpenID Connect working group relatively soon.
>>
>> We hope that other OpenID community members and organizations will provide 
>> feedback on how this list compares to their needs and/or get involved in 
>> flushing out the technical details.
>>
>> Here's the list of features that we would like to see implemented in a 
>> future version of OpenID:
>>
>> http://wiki.openid.net/Future-OpenID-Technical-Requirements
>>
>> Feedback and discussion is more than welcome!
>>
>> Allen
>>
>> ___
>> specs mailing list
>> sp...@lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>> ___
>> specs mailing list
>> sp...@lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: BC Government requirements for OpenID v.Next

[Nat Sakimura]

/document/?a=p275492430&d=ABC_of_OpenID-AB.key

The second one was presented at the OpenID Summit EU by John Bradley
yesterday.

>
>
> m)  The protocol should include an extension for how an identity
> provider should publish its
>
>capabilities (authentication methods and other security policies that
>   it can perform, and which
>
>   attributes it can supply), so that a relying party can determine
>   whether the identity provider is
>
>   capable of meeting its requirements.
>
> It is the job of XRDS for public data.

>From the privacy perspective, it is undesirable to publish where the
person's attribute can be
obtained before authorizing the relying party, because it may reveal some of
my privacy.
For example, if it is published that my work related data can be obtained
from https://data.nri.co.jp/,
then the viewer may infer that I am employed by NRI.

Thus, in AB (and CX), the in the first step, only the IdP is identified.
The relying party specifies the attribute in abstract terms, such as "work
phone".
Then, in the assertion which is created after the End User's authorization,
will contain the specific data server endpoints.

>
>
> n)  The protocol should be written such that different industries or
> communities can write profiles
>
>of it to satisfy their need to write standards that meet their specific
>   requirements for policies
>
>   and attribute exchanges.
>
> It depends on what you need to specify, but PAPE has an extension point,
AX is extensible from the beginning, so we can do a lot with them.

>
>
>  ***Patricia Wiebe*
> Senior Identity Architect, Architecture & Standards Branch
> Office of the Chief Information Officer, Province of BC
> Phone:  250.387.6818  Mobile: 250.514.7685
> Email:  patricia.wi...@gov.bc.ca
>
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [OpenID] Migrating User Identifier URL re: Connect

[Nat Sakimura]

So, who is going to draft the spec?

As I have stated earlier, I would like to generalize it a little bit more than
just openid2/connect.

This would be very useful to solve "the openid2 provider shutting down
problem" as well.

=nat

On Sat, May 29, 2010 at 2:51 PM, David Recordon  wrote:
> +1 Allen/John
>
> On Fri, May 28, 2010 at 11:35 AM, Allen Tom  wrote:
>>
>> Hi Nat -
>>
>> The high level strawman proposal that John Bradley and I briefly discussed
>> was:
>>
>> 1) return the user's OpenID 2.0 identifier as an attribute in the Connect
>> assertion (along with the new Connect ID)
>>
>> 2) Update the OpenID 2.0 discovery document for the identifier to list the
>> to OpenID Connect endpoint as a "connect/openid2" migration service.
>> Connect
>> RPs are supposed to perform OpenID 2.0 discovery on the OpenID 2.0
>> identifier to make sure that the Connect OP is also authorative for the
>> OpenID 2.0 identifier
>>
>> Implementing #1 and #2 will allow an existing OpenID 2.0 RP that already
>> has
>> OpenID 2.0 users to migrate their existing users to Connect without
>> requiring users to auth twice during the migration process.
>>
>> Does anyone see a problem with this approach?
>>
>> Allen
>>
>>
>> On 5/27/10 7:06 PM, "Nat Sakimura"  wrote:
>>
>> >
>> >
>> > My suggestion here is to include both the old and new identifier in a
>> > signed assertion,
>> > with a sunset set for the old identifier. It could be either OpenID
>> > assertion or XRDS.
>> > If it is in the OpenID assertion, it is done.
>> >
>> > If it got the old identifier as an attribute of the identity that the
>> > new identifier points to,
>> > RP can then do the Discovery on the old known
>> > identifier and get back the XRDS which includes both the old and new
>> > identifier.
>> >
>> > What do you think?
>>
>> ___
>> general mailing list
>> gene...@lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-general
>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Migrating User Identifier URL re: Connect

[Nat Sakimura]

That is very similar. However, I would rather position it not as
"openid2/connect" migration but "oldid/newid" migration service. That
way, we can use it even for openid2 idp to openid2 idp migration or
connect idp to connect idp migration.

=nat

On Sat, May 29, 2010 at 3:35 AM, Allen Tom  wrote:
> Hi Nat -
>
> The high level strawman proposal that John Bradley and I briefly discussed
> was:
>
> 1) return the user's OpenID 2.0 identifier as an attribute in the Connect
> assertion (along with the new Connect ID)
>
> 2) Update the OpenID 2.0 discovery document for the identifier to list the
> to OpenID Connect endpoint as a "connect/openid2" migration service. Connect
> RPs are supposed to perform OpenID 2.0 discovery on the OpenID 2.0
> identifier to make sure that the Connect OP is also authorative for the
> OpenID 2.0 identifier
>
> Implementing #1 and #2 will allow an existing OpenID 2.0 RP that already has
> OpenID 2.0 users to migrate their existing users to Connect without
> requiring users to auth twice during the migration process.
>
> Does anyone see a problem with this approach?
>
> Allen
>
>
> On 5/27/10 7:06 PM, "Nat Sakimura"  wrote:
>
>>
>>
>> My suggestion here is to include both the old and new identifier in a
>> signed assertion,
>> with a sunset set for the old identifier. It could be either OpenID
>> assertion or XRDS.
>> If it is in the OpenID assertion, it is done.
>>
>> If it got the old identifier as an attribute of the identity that the
>> new identifier points to,
>> RP can then do the Discovery on the old known
>> identifier and get back the XRDS which includes both the old and new
>> identifier.
>>
>> What do you think?
>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [OpenID] Migrating User Identifier URL re: Connect

[Nat Sakimura]

I meant, "it is userful when the user is moving the idp as well."

iPad typing is not always as easy as it should be ...

=nat

On Sat, May 29, 2010 at 11:16 AM, Nat Sakimura  wrote:
> It is useful when the use is moving the idp as well.
> RP doing the check would be also interesting though the RP has to be somehow
> authenticated, I suppose, to thwart the identifier harvesting for the
> correlation. It would also be good to define a bulk check protocol. We did
> some experiment around that back in February by the Ministry of Internal
> Affairs and Communication. Perhaps we can do some international  R&D/pilot
> on this topic this year?
> =nat via iPad
> On 2010/05/29, at 3:13, George Fletcher  wrote:
>
> This is similar to the IIW talk I did about migrating HTTP OpenIDs to HTTPS
> OpenIDs. In general, it would be great if there was a standard way for RPs
> to know and deal with OPs changing the identifiers. Using discovery (over
> SSL?) to determine the two identifiers "point" to the same Authorization
> server makes sense to me.
>
> If it's possible to discover the new identifier from the old one, then RPs
> can just go through their DB and do the mapping out-of-band (meaning the
> user doesn't have to be present). This can easy migration efforts from a
> deployment perspective.
>
> Thanks,
> George
>
> On 5/27/10 10:06 PM, Nat Sakimura wrote:
>
> The Connect proposal has put forward the new discovery and new
> identifier for the user.
> The RP will get the old identifier only through the request to the new
> identifier.
> It is done pretty cleanly though there are some downsides. Namely:
>
> 1) User is now bound to the authentication service.
> 2) Current RP will be screwed up because there is no strong link
> between the current and new identifiers.
>
> Among the two, 1) is relatively benign. Most of the current OpenID 2.0
> providers are like that.
> (Though I would still want to seek more user centric way of doing things.)
> In contrast, 2) is a disaster for the current RPs.
>
> What the RPs needs to do then is to authenticate the user that has
> come in with connect proposal
> with the good old OpenID 2.0 again to make the identity linking, which
> in general is not a very
> good user experience.
>
> My suggestion here is to include both the old and new identifier in a
> signed assertion,
> with a sunset set for the old identifier. It could be either OpenID
> assertion or XRDS.
> If it is in the OpenID assertion, it is done.
>
> If it got the old identifier as an attribute of the identity that the
> new identifier points to,
> RP can then do the Discovery on the old known
> identifier and get back the XRDS which includes both the old and new
> identifier.
>
> What do you think?
>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [OpenID] Migrating User Identifier URL re: Connect

[Nat Sakimura]

It is useful when the use is moving the idp as well. 

RP doing the check would be also interesting though the RP has to be somehow 
authenticated, I suppose, to thwart the identifier harvesting for the 
correlation. It would also be good to define a bulk check protocol. We did some 
experiment around that back in February by the Ministry of Internal Affairs and 
Communication. Perhaps we can do some international  R&D/pilot on this topic 
this year? 

=nat via iPad

On 2010/05/29, at 3:13, George Fletcher  wrote:

> This is similar to the IIW talk I did about migrating HTTP OpenIDs to HTTPS 
> OpenIDs. In general, it would be great if there was a standard way for RPs to 
> know and deal with OPs changing the identifiers. Using discovery (over SSL?) 
> to determine the two identifiers "point" to the same Authorization server 
> makes sense to me.
> 
> If it's possible to discover the new identifier from the old one, then RPs 
> can just go through their DB and do the mapping out-of-band (meaning the user 
> doesn't have to be present). This can easy migration efforts from a 
> deployment perspective.
> 
> Thanks,
> George
> 
> On 5/27/10 10:06 PM, Nat Sakimura wrote:
>> 
>> The Connect proposal has put forward the new discovery and new
>> identifier for the user.
>> The RP will get the old identifier only through the request to the new
>> identifier.
>> It is done pretty cleanly though there are some downsides. Namely:
>> 
>> 1) User is now bound to the authentication service.
>> 2) Current RP will be screwed up because there is no strong link
>> between the current and new identifiers.
>> 
>> Among the two, 1) is relatively benign. Most of the current OpenID 2.0
>> providers are like that.
>> (Though I would still want to seek more user centric way of doing things.)
>> In contrast, 2) is a disaster for the current RPs.
>> 
>> What the RPs needs to do then is to authenticate the user that has
>> come in with connect proposal
>> with the good old OpenID 2.0 again to make the identity linking, which
>> in general is not a very
>> good user experience.
>> 
>> My suggestion here is to include both the old and new identifier in a
>> signed assertion,
>> with a sunset set for the old identifier. It could be either OpenID
>> assertion or XRDS.
>> If it is in the OpenID assertion, it is done.
>> 
>> If it got the old identifier as an attribute of the identity that the
>> new identifier points to,
>> RP can then do the Discovery on the old known
>> identifier and get back the XRDS which includes both the old and new
>> identifier.
>> 
>> What do you think?
>> 
>>   
> 
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Migrating User Identifier URL re: Connect

[Nat Sakimura]

The Connect proposal has put forward the new discovery and new
identifier for the user.
The RP will get the old identifier only through the request to the new
identifier.
It is done pretty cleanly though there are some downsides. Namely:

1) User is now bound to the authentication service.
2) Current RP will be screwed up because there is no strong link
between the current and new identifiers.

Among the two, 1) is relatively benign. Most of the current OpenID 2.0
providers are like that.
(Though I would still want to seek more user centric way of doing things.)
In contrast, 2) is a disaster for the current RPs.

What the RPs needs to do then is to authenticate the user that has
come in with connect proposal
with the good old OpenID 2.0 again to make the identity linking, which
in general is not a very
good user experience.

My suggestion here is to include both the old and new identifier in a
signed assertion,
with a sunset set for the old identifier. It could be either OpenID
assertion or XRDS.
If it is in the OpenID assertion, it is done.

If it got the old identifier as an attribute of the identity that the
new identifier points to,
RP can then do the Discovery on the old known
identifier and get back the XRDS which includes both the old and new
identifier.

What do you think?

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: OpenID Hybrid v2 Proposal (formerly known OpenID Connect)

[Nat Sakimura]

Eran,

Just to let you know: OpenID Foundation has been working on the
identity layer on top of OAuth for several months already.
The draft spec of the Artifact Binding WG is 90% same as the Connect
proposal. If OAuth2.0 defines a "Request in a file"
or "Mobile Web App" kind of flow, it will be 95% the same. Admittedly,
it lacks the Discovery portion of the
Connect proposal, but that is to be dealt with v.Next Discovery led by
Allen Tom.

Just have a look: https://openid4.us/specs/ab/

Regards,

Nat

On Wed, May 26, 2010 at 5:22 PM, Eran Hammer-Lahav  wrote:
> Discussing the name is a distraction. The issue is whether the OpenID 
> foundation wants to be where identity work is done, or where the OpenID 
> protocol (and nothing else) is done. Again, the question is very simple: 
> OAuth is going to have an identity layer (that's a done deal) - do you want 
> to work on it here under the OpenID foundation or not?
>
> Everything else (like naming, migration path from OpenID 2.0 to OAuth 2.0 
> identity) is stuff for the WG to figure out.
>
> This is a fundamental question far beyond all this geek talk: what is the 
> purpose of this community? Where are its boundaries? Is this the hub of web 
> identity work, or just one tiny piece of it?
>
> I'm happy with any answer.
>
> It would be helpful if people would voice clear opinions on this rather than 
> going in circles (i.e., start with "I'm for/against doing this work here, and 
> this is why...").
>
> EHL
>
>> -Original Message-
>> From: openid-specs-boun...@lists.openid.net [mailto:openid-specs-
>> boun...@lists.openid.net] On Behalf Of Martin Atkins
>> Sent: Tuesday, May 25, 2010 5:49 PM
>> To: openid-specs@lists.openid.net
>> Subject: Re: OpenID Hybrid v2 Proposal (formerly known OpenID Connect)
>>
>> On 05/25/2010 01:56 PM, Allen Tom wrote:
>> > Hi All,
>> >
>> > A better way to look at OpenID Connect is to just think of it as
>> > revised version of the OpenID Hybrid. The purpose of the Hybrid WG was
>> > to find a way to combine OpenID Authentication with the approval of an
>> > Oauth access token into a single request/response.
>> >
>>
>> "OpenID Connect" isn't actually compatible with OpenID at anything but the
>> highest conceptual level.
>>
>> > Renaming the OpenID Connect WG to be the OpenID Hybrid v2 WG could
>> > possibly clarify the goals of the WG, and reduce confusion within the
>> community.
>> > Afterall - Hybrid is intended for the case where the user's IdP is
>> > also the SP, so the Connect proposal is really a revised Hybrid
>> > proposal, rather than a proposal for OpenID v.Next
>> >
>>
>> I think this would only make sense if the resulting protocol were 
>> functionally
>> equivalent to OpenID. That is to say that I can implement it against my
>> existing OpenID infrastructure without doing data migrations, changing my
>> UI, etc.
>>
>> I think the most important deviation in OpenID Connect is that the identifier
>> is no longer expected to be human-readable; while I completely agree that
>> this is the right design if we're starting over from a clean slate, that's a
>> breaking change for most existing consumer implementations that link to the
>> identifier as the user's "home page" or "profile page".
>>
>> I still think this thing should be branded with a stronger OAuth connotation
>> than an OpenID connotation, since it's far closer to OAuth than it is to
>> OpenID. I didn't really like the OpenID Connect name, but at least it made it
>> sound like this was something new and different; calling it OpenID/OAuth
>> Hybrid makes it sound a lot more like a different implementation of the same
>> thing than the radical rethink that OpenID Connect actually represents.
>>
>> That's my two cents, at least.
>>
>>
>>
>> ___
>> specs mailing list
>> sp...@lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [OIDFSC] OpenID v.Next Discovery Working Group Proposal

[Nat Sakimura]

Is there a free hosting service for that? That seems to be the biggest
difference here.

=nat

2010/5/25 Phillip Hallam-Baker :
> Why not just copy the scheme that the W3C uses?
>
> They have an issue tracker and a bunch of other stuff and I am pretty
> sure it is all based on open source. The only part that isn't is their
> conference bridge with an IRC interface which is really cool but
> requires a commercial bridge.
>
> Now if someone did that in Asterisk...
>
>
> 2010/5/25 Nat Sakimura :
>> >From the "commoner's" perspective, hg.openid.net and bitbucket.org/openid
>> is somewhat different. Whether "openid" is in the "authority" segment or not
>> makes the difference.
>>
>> For tools, wiki is sub-optimal for issue tracking. For that matter, I agree
>> that bitbucket.org's issue tracking neither comes to my expectation, but at
>> least, I would not have to set a server up or create new identity. I can
>> reuse my openid.
>>
>> Ideally, it should be something that allows us to:
>>
>> - Use OpenID to login
>> - Track the changes.
>> - Issue should be assigned
>>   - the expected end date
>>   - person in charge
>>   - status
>>
>> This will greately simplify our lives. Wiki is not so good for these when
>> many issues starts to accumulate. FYI, I use redmine for my day job projects
>> and are fairly good, but it is not a hosted solution.
>>
>> =nat
>>
>> (2010/05/25 13:05), David Recordon wrote:
>>
>> Or continue using BitBucket without a custom domain. I'm all for tools, but
>> mercurial.openid.net versus bitbucket.com/openid doesn't feel like a large
>> difference.
>>
>> On Mon, May 24, 2010 at 9:09 PM, Dick Hardt  wrote:
>>>
>>> While I am a fan of using tools to simplify our lives, I am concerned that
>>> we have setup a number of tools that seemed like a good idea and did not get
>>> utilized.
>>> I am fearful that community members will spend time on a new tool, only to
>>> be disappointed in lack of use.
>>>
>>> How about we just use the wiki we have now to create a document we can all
>>> edit?
>>>
>>> -- Dick
>>>
>>> On 2010-05-24, at 7:24 PM, Nat Sakimura wrote:
>>>
>>> > There are various plans, but since OIDF is primarily operating in
>>> > public,
>>> > I should think that "Amateur" plan would suffice. It is US$5/mo.
>>> > The limitation is that it can only have one private repository,
>>> > but that should be ok.
>>> >
>>> > =nat
>>> >
>>> > (2010/05/25 1:56), Brian Kissel wrote:
>>> >> What is the cost? The Tech Committee has some budget.
>>> >>
>>> >> Cheers,
>>> >>
>>> >> Brian
>>> >> ___
>>> >>
>>> >> Brian Kissel
>>> >> CEO - JanRain, Inc.
>>> >> bkis...@janrain.com
>>> >> Mobile: 503.342.2668 | Fax: 503.296.5502
>>> >> 519 SW 3rd Ave. Suite 600  Portland, OR 97204
>>> >>
>>> >> Increase registrations, engage users, and grow your brand with RPX.
>>> >>  Learn
>>> >> more at www.rpxnow.com
>>> >>
>>> >>
>>> >> -Original Message-
>>> >> From: openid-specs-boun...@lists.openid.net
>>> >> [mailto:openid-specs-boun...@lists.openid.net] On Behalf Of Nat
>>> >> Sakimura
>>> >> Sent: Monday, May 24, 2010 8:05 AM
>>> >> To: Johannes Ernst
>>> >> Cc: OpenID Specs Mailing List
>>> >> Subject: Re: [OIDFSC] OpenID v.Next Discovery Working Group Proposal
>>> >>
>>> >> Good idea.
>>> >>
>>> >> I can setup a project under bitbucket.org/openid/ (shall we upgrade to
>>> >> non-free version
>>> >> so that we get it under openid.net?) and it has a rudimentary bug
>>> >> tracking system.
>>> >> It can be used by logging in by OpenID.
>>> >>
>>> >> =nat
>>> >>
>>> >> On Mon, May 24, 2010 at 11:50 AM, Johannes Ernst
>>> >>   wrote:
>>> >>
>>> >>> Allen, combining what you just wrote with what Brian said on the board
>>> >>> mailing list about MRDs -- perhaps it would make sense to set up a
>>> >>> "bug
>>> >>

Re: Why Connect?

[Nat Sakimura]

A bit of comment.

On Tue, May 25, 2010 at 4:57 AM, David Recordon  wrote:
>
> Allen Tom:
>>
>> Connect has a well defined scope that standardizes an identity interface
>> using OAuth – which has already been widely implemented and has already
>> proven to work by several vendors. Based on adoption, It’s obvious that the
>> marketplace wants this. Given that there are several widely implemented and
>> very successful implementations of Identity using Oauth – its pretty
>> straightforward and almost obvious how to build OpenID Connect by taking the
>> best practices of what’s already been implemented.
>>
>> I do think that the community would be better off if we could drop the
>> Connect branding. Perhaps we can call it OpenID 3.0 Core, and the use cases
>> that are in the v.Next Proposal that are not in Core can be built on top of
>> 3.0 Core.
>

I agree with Allen.

I like the architecture. It basically is (OpenID Artifact Binding) +
(New Disco & Assoc) -  (features that
support LoA1+ (such as magic signature, etc.) ).

For those of you who are not acquainted with OpenID Artifact Binding
(or for Mobile),
it is a binding of OpenID on OAuth2.0 with some appropriate restriction on
"code" length etc. (As it so happens, it does not require Association
since we do it over SSL.)

The differences are:

1. Artifact Binding (AB) returns identity assertion in parallel to the
OAuth access token,
  thus AB can return identity attributes and other extension variables
within assertion - better compatibility.
  Also, it is one less round trip than Connect.
2. AB defines public key based sig. through the Magic Signature and some
additional parameters so that it can go up to LoA4.
3. Connect defines new discovery.

Otherwise, they are pretty much the same thing.

Anyways, my biggest concern is the market confusion.

"Connect" simply can be the basic building bloc and the first
deliverable of the
v.Next Core WG.

If that would be the course, I will give a full support to the connect,
though I might still want to ask "why duplicate with Artifact Binding?" ;-)
It simply looks like a too much overlap.

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [OIDFSC] OpenID v.Next Discovery Working Group Proposal

[Nat Sakimura]

>From the "commoner's" perspective, hg.openid.net and
bitbucket.org/openid is somewhat different. Whether "openid" is in the
"authority" segment or not makes the difference.

For tools, wiki is sub-optimal for issue tracking. For that matter, I
agree that bitbucket.org's issue tracking neither comes to my
expectation, but at least, I would not have to set a server up or create
new identity. I can reuse my openid.

Ideally, it should be something that allows us to:

- Use OpenID to login
- Track the changes.
- Issue should be assigned
- the expected end date
- person in charge
- status

This will greately simplify our lives. Wiki is not so good for these
when many issues starts to accumulate. FYI, I use redmine for my day job
projects and are fairly good, but it is not a hosted solution.

=nat

(2010/05/25 13:05), David Recordon wrote:
> Or continue using BitBucket without a custom domain. I'm all for
> tools, but mercurial.openid.net <http://mercurial.openid.net> versus
> bitbucket.com/openid <http://bitbucket.com/openid> doesn't feel like a
> large difference.
>
>
> On Mon, May 24, 2010 at 9:09 PM, Dick Hardt  <mailto:dick.ha...@gmail.com>> wrote:
>
> While I am a fan of using tools to simplify our lives, I am
> concerned that we have setup a number of tools that seemed like a
> good idea and did not get utilized.
> I am fearful that community members will spend time on a new tool,
> only to be disappointed in lack of use.
>
> How about we just use the wiki we have now to create a document we
> can all edit?
>
> -- Dick
>
> On 2010-05-24, at 7:24 PM, Nat Sakimura wrote:
>
> > There are various plans, but since OIDF is primarily operating
> in public,
> > I should think that "Amateur" plan would suffice. It is US$5/mo.
> > The limitation is that it can only have one private repository,
> > but that should be ok.
> >
> > =nat
> >
> > (2010/05/25 1:56), Brian Kissel wrote:
> >> What is the cost? The Tech Committee has some budget.
> >>
> >> Cheers,
> >>
> >> Brian
> >> ___
> >>
> >> Brian Kissel
> >> CEO - JanRain, Inc.
> >> bkis...@janrain.com <mailto:bkis...@janrain.com>
> >> Mobile: 503.342.2668 | Fax: 503.296.5502
> >> 519 SW 3rd Ave. Suite 600 Portland, OR 97204
> >>
> >> Increase registrations, engage users, and grow your brand with
> RPX. Learn
>     >> more at www.rpxnow.com <http://www.rpxnow.com>
> >>
> >>
> >> -Original Message-
> >> From: openid-specs-boun...@lists.openid.net
> <mailto:openid-specs-boun...@lists.openid.net>
> >> [mailto:openid-specs-boun...@lists.openid.net
> <mailto:openid-specs-boun...@lists.openid.net>] On Behalf Of Nat
> Sakimura
> >> Sent: Monday, May 24, 2010 8:05 AM
> >> To: Johannes Ernst
> >> Cc: OpenID Specs Mailing List
> >> Subject: Re: [OIDFSC] OpenID v.Next Discovery Working Group
> Proposal
> >>
> >> Good idea.
> >>
> >> I can setup a project under bitbucket.org/openid/
> <http://bitbucket.org/openid/> (shall we upgrade to
> >> non-free version
> >> so that we get it under openid.net <http://openid.net>?) and it
> has a rudimentary bug
> >> tracking system.
> >> It can be used by logging in by OpenID.
> >>
> >> =nat
> >>
> >> On Mon, May 24, 2010 at 11:50 AM, Johannes Ernst
> >> http://openid.net>@netmesh.us
> <http://netmesh.us>> wrote:
> >>
> >>> Allen, combining what you just wrote with what Brian said on
> the board
> >>> mailing list about MRDs -- perhaps it would make sense to set
> up a "bug
> >>> tracking system" of some kind and use that to drive spec
> evolution?
> >>> On May 23, 2010, at 18:56, Allen Tom wrote:
> >>>
> >>> Hi Johannes,
> >>>
> >>> There isn't a document summarizing the deficiencies with
> OpenID 2.0
> >>> discovery - I think it would be very useful for the WG and for the
> >>>
> >> Community
> >>
> >>> if we wrote this down
> >>>
> >>> Off the top of my head, some of the proble

Re: v.Next NewSocialService scenario

[Nat Sakimura]

The scenario itself is one of the main one that CX working group is 
tackling right now.
It is not easy, but it is very valuable from both the usability to the 
users and RPs.


Do you suppose that the data is going through the OP or RP is going to make
direct requests to Twitter, Linkedin etc. ?

=nat

(2010/05/25 12:59), Dick Hardt wrote:

Below is a vision I have described on how v.Next may evolve that calls out how 
it relates to OAuth. Hoepfully this will provoke some discussion around v.Next.

-- Dick

User navigates to site where they can sign up for a NewSocialService. 
NewSocialService works well if it calls APIs at Facebook and/or Twitter and/or 
Linkedin. It also would like to help the user find and/or invite friends to the 
NewService. Access to the user's calendar makes NewSocialService really sing as 
well as the user's list of favourite restaurants. If the user is a frequent 
flyer, they also will get some special promotional offers.

A) The user provides NewSocialService (the RP) with their OP

B) NewSocialService makes an OpenID v.Next request to the OP to get:
 OAuth 2.0 access tokens for:
- Facebook
- Twitter
- LinkedIn OAuth 2.0 access token
- portable contacts API
- calendar API
favorite restaurant list
frequent flyer credential
verified email address

C) The user's OP looks at the request, sees that the user has an account at 
Twitter and LinkedIn, but not Facebook, their portable contacts at Yahoo! and 
their calendar at Google.  The user has delegated the OP to be able to 
re-delegate access to all of these services. (ie. the OP has an OAuth 2.0 
access token that enables the OP to delegate access to these services on behalf 
of the user) The OP sees the user is a member of AlaskaAir frequent flyer 
program.

D) The OP presents a screen to the user asking them to confirm the release of:
- access to Twitter API
- access to LinkedIn API
- read access to portable contacts API at Yahoo!
- read access to calendar at Google
- list of favourite restaurants
- AlaskaAir frequent flyer credential
- email address

E) The user consents and the OP makes a re-delegation request to Twitter, 
LinkedIn, Yahoo! and Google. The OP puts the results into a magic bundle and 
magicly transmits it to the RP.
The RP verifies the response and acquires access tokens for Twitter, LinkedIn, 
Yahoo! and Google.
The RP verifies the email address claim and the frequent flyer claim
The RP (NewSocialService) starts providing a cool, new social service.

NOTES:

1) The RP makes one request, the user performs one consent operation.
2) The OP may or may not be Facebook, Twitter, LinkedIn, Yahoo! or Google. ie, 
the OP may also be a service provide
3) The RP may or may not have had to have been registered with Twitter, 
LinkedIn, Yahoo! and Google. That is an orthogonal requirement that is set by 
the service.
4) Re-delegation is not part of OAuth 2.0 at this time. This scenario hopefully 
illustrates the value of re-delegation.
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs
   



--
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
PLEASE READ:
The information contained in this e-mail is confidential and intended for the 
named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified 
that any review, dissemination, distribution or duplication of this message is 
strictly prohibited. If you have received this message in error, please notify 
the sender immediately and delete your copy from your system.


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

Re: [OIDFSC] OpenID v.Next Discovery Working Group Proposal

[Nat Sakimura]

There are various plans, but since OIDF is primarily operating in public,
I should think that "Amateur" plan would suffice. It is US$5/mo.
The limitation is that it can only have one private repository,
but that should be ok.

=nat

(2010/05/25 1:56), Brian Kissel wrote:

What is the cost? The Tech Committee has some budget.

Cheers,

Brian
___

Brian Kissel
CEO - JanRain, Inc.
bkis...@janrain.com
Mobile: 503.342.2668 | Fax: 503.296.5502
519 SW 3rd Ave. Suite 600  Portland, OR 97204

Increase registrations, engage users, and grow your brand with RPX.  Learn
more at www.rpxnow.com


-Original Message-
From: openid-specs-boun...@lists.openid.net
[mailto:openid-specs-boun...@lists.openid.net] On Behalf Of Nat Sakimura
Sent: Monday, May 24, 2010 8:05 AM
To: Johannes Ernst
Cc: OpenID Specs Mailing List
Subject: Re: [OIDFSC] OpenID v.Next Discovery Working Group Proposal

Good idea.

I can setup a project under bitbucket.org/openid/ (shall we upgrade to
non-free version
so that we get it under openid.net?) and it has a rudimentary bug
tracking system.
It can be used by logging in by OpenID.

=nat

On Mon, May 24, 2010 at 11:50 AM, Johannes Ernst
  wrote:
   

Allen, combining what you just wrote with what Brian said on the board
mailing list about MRDs -- perhaps it would make sense to set up a "bug
tracking system" of some kind and use that to drive spec evolution?
On May 23, 2010, at 18:56, Allen Tom wrote:

Hi Johannes,

There isn't a document summarizing the deficiencies with OpenID 2.0
discovery - I think it would be very useful for the WG and for the
 

Community
   

if we wrote this down

Off the top of my head, some of the problems are:

Yadis discovery is very vague as to exactly how the RP is supposed to
 

fetch
   

the OP's discovery document. Should it send the magic Accept header?
 

Look
   

for the X-XRDS-Location header in the response? Do HTML discovery? In
practice, many implementers have had problems implementing discovery
 

because
   

there are too many ways to do it
Speaking of Yadis, the specs need to be revised, and it's unclear how to
 

go
   

about doing this
Because a compromised discovery document can result in the complete
breakdown in OpenID security - it's important that we find ways to
 

increase
   

the security of discovery - perhaps it can be signed? Moved into DNS?
Discovery is hard to implement - the majority of the code in OpenID
libraries is to implement discovery. We can probably simplify discovery
 

to
   

require less code to implement
Delegation is a really useful feature in OpenID - it was pretty
straightforward in OpenID 1.1, but is very confusing (to say the least)
 

in
   

OpenID 2.0 - we can probably do something in discovery to make
 

delegation
   

work better
The infamous NASCAR problem could possibly be helped by discovery
The infamous phishing problem could also possibly be helped by discovery
LRDD, host-meta, and webfinger are pretty interesting - we should see
 

how
   

OpenID can leverage these new specs

I'm sure that there are more issues with OpenID 2.0 discovery. Anyone
 

else
   

want to take a stab at it?

Allen


On 5/21/10 7:55 PM, "Johannes Ernst"
 

wrote:
   

On May 21, 2010, at 19:28, Allen Tom wrote:

... there's universal consensus that the existing OpenID 2.0 discovery
mechanism is very deficient ...

Is there a summary somewhere of this "universal consensus" of
 

deficiencies?
   

Thanks,


Johannes Ernst
NetMesh Inc.






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


 



   



--
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
PLEASE READ:
The information contained in this e-mail is confidential and intended for the 
named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified 
that any review, dissemination, distribution or duplication of this message is 
strictly prohibited. If you have received this message in error, please notify 
the sender immediately and delete your copy from your system.


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

Re: [OIDFSC] OpenID v.Next Discovery Working Group Proposal

[Nat Sakimura]

Good idea.

I can setup a project under bitbucket.org/openid/ (shall we upgrade to
non-free version
so that we get it under openid.net?) and it has a rudimentary bug
tracking system.
It can be used by logging in by OpenID.

=nat

On Mon, May 24, 2010 at 11:50 AM, Johannes Ernst
 wrote:
> Allen, combining what you just wrote with what Brian said on the board
> mailing list about MRDs -- perhaps it would make sense to set up a "bug
> tracking system" of some kind and use that to drive spec evolution?
> On May 23, 2010, at 18:56, Allen Tom wrote:
>
> Hi Johannes,
>
> There isn’t a document summarizing the deficiencies with OpenID 2.0
> discovery – I think it would be very useful for the WG and for the Community
> if we wrote this down
>
> Off the top of my head, some of the problems are:
>
> Yadis discovery is very vague as to exactly how the RP is supposed to fetch
> the OP’s discovery document. Should it send the magic Accept header? Look
> for the X-XRDS-Location header in the response? Do HTML discovery? In
> practice, many implementers have had problems implementing discovery because
> there are too many ways to do it
> Speaking of Yadis, the specs need to be revised, and it’s unclear how to go
> about doing this
> Because a compromised discovery document can result in the complete
> breakdown in OpenID security – it’s important that we find ways to increase
> the security of discovery – perhaps it can be signed? Moved into DNS?
> Discovery is hard to implement – the majority of the code in OpenID
> libraries is to implement discovery. We can probably simplify discovery to
> require less code to implement
> Delegation is a really useful feature in OpenID – it was pretty
> straightforward in OpenID 1.1, but is very confusing (to say the least) in
> OpenID 2.0 – we can probably do something in discovery to make delegation
> work better
> The infamous NASCAR problem could possibly be helped by discovery
> The infamous phishing problem could also possibly be helped by discovery
> LRDD, host-meta, and webfinger are pretty interesting – we should see how
> OpenID can leverage these new specs
>
> I’m sure that there are more issues with OpenID 2.0 discovery. Anyone else
> want to take a stab at it?
>
> Allen
>
>
> On 5/21/10 7:55 PM, "Johannes Ernst"  wrote:
>
> On May 21, 2010, at 19:28, Allen Tom wrote:
>
> ... there’s universal consensus that the existing OpenID 2.0 discovery
> mechanism is very deficient ...
>
> Is there a summary somewhere of this "universal consensus" of deficiencies?
>
> Thanks,
>
>
> Johannes Ernst
> NetMesh Inc.
>
>
>
>
>
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [OIDFSC] OpenID v.Next Discovery Working Group Proposal

[Nat Sakimura]

When it comes to delegation, it probably is the discovery service that 
has to turn the user supplied identifier to a persistent identifier. 
Unfortunately, it is not done so right now, and it is the authentication 
service that does it.
If we really need the delegation feature, this is one of the thing that 
we should probably be addressing as well.


Please see also a series of blog entries :

http://www.sakimura.org/en/search.php?query=Discovery&action=results 
<http://us1.sakimura.org/en/search.php?query=Discovery&action=results>


Cheers,

=nat

(2010/05/24 10:56), Allen Tom wrote:

Hi Johannes,

There isn't a document summarizing the deficiencies with OpenID 2.0 
discovery -- I think it would be very useful for the WG and for the 
Community if we wrote this down


Off the top of my head, some of the problems are:

* Yadis discovery is very vague as to exactly how the RP is
  supposed to fetch the OP's discovery document. Should it send
  the magic Accept header? Look for the X-XRDS-Location header in
  the response? Do HTML discovery? In practice, many implementers
  have had problems implementing discovery because there are too
  many ways to do it
* Speaking of Yadis, the specs need to be revised, and it's
  unclear how to go about doing this
* Because a compromised discovery document can result in the
  complete breakdown in OpenID security -- it's important that we
  find ways to increase the security of discovery -- perhaps it
  can be signed? Moved into DNS?
* Discovery is hard to implement -- the majority of the code in
  OpenID libraries is to implement discovery. We can probably
  simplify discovery to require less code to implement
* Delegation is a really useful feature in OpenID -- it was pretty
  straightforward in OpenID 1.1, but is very confusing (to say the
  least) in OpenID 2.0 -- we can probably do something in
  discovery to make delegation work better
* The infamous NASCAR problem could possibly be helped by discovery
* The infamous phishing problem could also possibly be helped by
  discovery
* LRDD, host-meta, and webfinger are pretty interesting -- we
  should see how OpenID can leverage these new specs


I'm sure that there are more issues with OpenID 2.0 discovery. Anyone 
else want to take a stab at it?


Allen


On 5/21/10 7:55 PM, "Johannes Ernst"  wrote:

On May 21, 2010, at 19:28, Allen Tom wrote:

... there's universal consensus that the existing OpenID 2.0
discovery mechanism is very deficient ...


Is there a summary somewhere of this "universal consensus" of
deficiencies?

Thanks,


Johannes Ernst
NetMesh Inc.





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



--
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547


PLEASE READ:
The information contained in this e-mail is confidential and intended for the 
named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified 
that any review, dissemination, distribution or duplication of this message is 
strictly prohibited. If you have received this message in error, please notify 
the sender immediately and delete your copy from your system.

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

Re: Connect Work Group proposal

[Nat Sakimura]

So, the below seems to be the requirements that are not addressed by
either the existing specs or working groups that are in the Connect WG
charter proposal.

- Drastically reduce the complexity of discovery
- Support optional static verification of the token response via a
  signature using symmetric keys
- Support the ability to login to non-web browser applications such
  as desktop applications
- Support dynamic registration of clients

Is that right?

=nat
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: OpenID versus oAuth 2

[Nat Sakimura]

Thanks Santosh.

It can definitely be written in Python easily as well.
I have put an implementation at https://openid4.us/ to make sure that
the spec works, but it took only a couple of days including my
learning Javascript for the first time.

Please go ahead and experiment with Python as well.
Trying to do it on GAE might be an interesting experiment.

A friend of mine says he is going to do it on Ruby,
and there is somebody who is working on Java right now.
(It may well be complete already.)

=nat

2010/5/18 Santosh Rajan :
> This is very good work.
> I must admit that I never took a good look at artifact binding. Because I
> had this impression that artifact binding is about AX. Now that I have read
> the spec I can see that there is much more to it than AX. It looks more like
> a rewrite of the core protocol itself.
> Yes I know this is going to raise some eyebrows here. But seriously, all we
> need to do is add webfinger to this and Viola we have OpenID V.Next.
> (Yes I agree it is not as simple as that, but I hope you get the gist of
> what i am suggesting).
> Also will it be possible to try this out in other languages like python, i
> mean can we have a trial OP setup somewhere.
>
> On Tue, May 18, 2010 at 4:03 PM, Nat Sakimura  wrote:
>>
>> The same with Artifact Binding 1.0 draft 06. It is a chartered work group
>> at OpenID Foundation.
>> (OpenID Connect / v.Next etc. needs to be chartered and approved yet.)
>> It is very similar to David's straw man. Main difference is that you still
>> can get the same
>> identifier as OpenID 2.0. It also is a trivially implementable spec.
>>
>> See here: https://openid4.us/ for links etc.
>>
>> Cheers,
>>
>> =nat
>>
>>
>> (2010/05/17 22:27), Alex Barth wrote:
>>>
>>> Small aside: I've implemented a similar workflow myself recently and I've
>>> avoided any changes of user account details on Relying Parties:
>>>
>>> http://developmentseed.org/blog/2010/mar/02/simple-sign-openid
>>>
>>> All changes to accounts properties (user name, email, etc) are done on
>>> the provider to avoid asynchronicities.
>>>
>>> Alex
>>>
>>> On May 17, 2010, at 12:03 AM, Manuel Lemos wrote:
>>>
>>>> Hello,
>>>>
>>>> With this thread of using oAuth 2 for identity I am confused to which
>>>> protocol should I use for a single sign-on solution that I need to
>>>> implement.
>>>>
>>>> Let me explain my case and see if anybody can clarify what is the best
>>>> solution for me.
>>>>
>>>> I have one site, lets call it site A, that has many user accounts. I
>>>> want to build another site, lets call it site B, but I do not want users
>>>> with accounts in site A to create new accounts to access site B. They
>>>> could just use the same account data from site A and use it in site B.
>>>> In the future I may have sites C, D, etc..
>>>>
>>>> I thought of creating an OpenID authentication server, lets call it OP,
>>>> and migrate user account from site A to OP. When users go to site A or B
>>>> and need to login, they are redirected via OpenID to OP for
>>>> authentication.
>>>>
>>>> If successful, OP passes site A or B the account, personal name, nick
>>>> name and e-mail when redirecting back to sites A or B, so those sites
>>>> always have copies of that account information for imediate use.
>>>>
>>>> If the user updates one of those details in site A or B, they push the
>>>> changes to OP and OP propagates the changes to the other site A or B
>>>> that also has the same user account.
>>>>
>>>>> From the specifications that I read, OpenID and its extensions can be
>>>>
>>>> used the way I need.
>>>>
>>>> This will all be used only within my network sites. I do not intend to
>>>> allow users to autheticate with external OpenID providers, nor I want
>>>> other sites to use my OpenID provider to authenticate in other sites.
>>>>
>>>> Since this is meant for use restricted to my sites, I could invent a
>>>> proprietary protocol, but I thought it was better to not reinvent the
>>>> wheel.
>>>>
>>>> I will develop all the necessary components to implement the OpenID
>>>> provider and consumers with the needed extensions. Actually the consumer
>>>> component is m

Re: Building identity on top of OAuth 2.0? (TAKE 2)

[Nat Sakimura]

Hi Dan,

Sorry for a slow reply.

Strictly speaking, we should not be talking the technical details in
sp...@openid.net,
but it should be done in specx-*...@openid.net, because the later is
IPR protected
while the former is not.

Not all the lists are active. Here is my shot in describing the tech
related lists:

> specs   OpenID Specifications Discussions

This is primarily the list for Working Group charter discussion.
Anybody can speak here means it is not IPR protected and causes
IPR contamination. Thus, even if somebody give a great idea here,
it cannot be incorporated in any spec.

> Openid-specs-ab Artifact Binding 1.0 Working Group

This working group was formed to address the needs of mobile as well
as higher security use cases. It is a chartered working group, so you
can talk about technical details. (You have to write an IPR
Contribution Agreement to join this list.)

FYI, spec home repository is http://bitbucket.org/openid/ab/ and I
have set up a sample implementation site (I needed it to test how the
coding goes) at https://openid4.us (read it as "OpenID for us".)

Although it aimed at mobile and higher security scenarios, it ended up
to be much simpler than OpenID Authentication 2.0. It is quite close
to spec freeze. I intend to do it by the end of May so that it will go
into 45 days public review period.

List Activity: Medium.


> Openid-specs-ax Attribute Exchange 1.1 Working Group

This working group was formed to make a small change to the AX1.0 so
that it will fulfill all the functionality of SREG1.1. Specifically,
it will define some basic mandatory profile parameters, privacy url,
and fetch parameters. It is more like an errata. It should be finished
in the same time-frame as in AB.

This is a chartered working group.

List activity: Low.

> specs-council   Specifications Council

This list is only for specification council members. It is used to discuss if
it would be a violation of IPR etc., when a working group is being formed.

> Specs-cxContract Exchange for dynamic exchange of legal contract
>   among the parties.
This working group is set to define a way to create multi-party
signed contract document that can be used as a token for data exchange
as well as one of the proofing material at the court when needed.

Since it has multi-party capability, user may be able to make
attribute exchange among multiple parties at once, instead of
going through the permission ceremony multiple time.
It improves the usability as well as the level of protection for
the user.

This is a chartered working group.

List Activity: Medium

> specs-pape  PAPE specification mailing list

This is a chartered working group, but the work has finished and
produced PAPE1.0 specification.

> Specs-uiUser Interface Working Group Specs list

It is a working group that deals with the user experience
improvement.

This is a chartered working group.

Did it help?

=nat

On Mon, May 17, 2010 at 7:54 PM, Dan Brickley  wrote:
> On Mon, May 17, 2010 at 11:42 AM, Nat Sakimura  wrote:
>> So, while David's "OpenID Connect" straw man has bunch of interesting
>> properties, there has been substantial work done in parallel in OpenID 
>> Foundation's own
>> Working Group.
>
> Great to see all this new work. I'd joined this openid-specs list
> expecting it to be the place where such things happen, ... looking at
> http://lists.openid.net/mailman/listinfo I see a pile of others
> including I now notice Openid-specs-ab.
>
> Would it be possible for OpenID insiders to give a quick run-through
> of these lists, ... which ones are active, where the work splits up
> between them, the kinds of participation you're looking for, etc?
>
> For technical members of the wider 'social Web' community, concerned
> to help with the evolution of OpenID, which of the following should we
> be tracking or participating in?
>
> From http://lists.openid.net/mailman/listinfo --
>
> Openid-adoption Committee to coordinate adoption, usability and
> marketing strategies
> board   [no description available]
> Code    [no description available]
> eu      General OpenID discussions relating to Europe
> general OpenID General Discussion
> Openid-government       Committee to Coordinate with National and Regional 
> Governments
> legal   Legal discussion around OpenID
> marketing       OpenID marketing
> security        Discussion around security and anti-phishing tactics
> specs   OpenID Specifications Discussions
> Openid-specs-ab Artifact Binding 1.0 Working Group
> Openid-specs-ax Attribute Exchange 1.1 Working Group
> specs-council   Specifications Council
> Specs-cx        Contract Exchange for dynamic exchange of legal contract
> among the parties.
> specs-pape      PAPE specification mailing list
> Specs-u

Re: OpenID versus oAuth 2

[Nat Sakimura]

The same with Artifact Binding 1.0 draft 06. It is a chartered work 
group at OpenID Foundation.

(OpenID Connect / v.Next etc. needs to be chartered and approved yet.)
It is very similar to David's straw man. Main difference is that you 
still can get the same

identifier as OpenID 2.0. It also is a trivially implementable spec.

See here: https://openid4.us/ for links etc.

Cheers,

=nat


(2010/05/17 22:27), Alex Barth wrote:


Small aside: I've implemented a similar workflow myself recently and 
I've avoided any changes of user account details on Relying Parties:


http://developmentseed.org/blog/2010/mar/02/simple-sign-openid

All changes to accounts properties (user name, email, etc) are done on 
the provider to avoid asynchronicities.


Alex

On May 17, 2010, at 12:03 AM, Manuel Lemos wrote:


Hello,

With this thread of using oAuth 2 for identity I am confused to which
protocol should I use for a single sign-on solution that I need to
implement.

Let me explain my case and see if anybody can clarify what is the best
solution for me.

I have one site, lets call it site A, that has many user accounts. I
want to build another site, lets call it site B, but I do not want users
with accounts in site A to create new accounts to access site B. They
could just use the same account data from site A and use it in site B.
In the future I may have sites C, D, etc..

I thought of creating an OpenID authentication server, lets call it OP,
and migrate user account from site A to OP. When users go to site A or B
and need to login, they are redirected via OpenID to OP for 
authentication.


If successful, OP passes site A or B the account, personal name, nick
name and e-mail when redirecting back to sites A or B, so those sites
always have copies of that account information for imediate use.

If the user updates one of those details in site A or B, they push the
changes to OP and OP propagates the changes to the other site A or B
that also has the same user account.


From the specifications that I read, OpenID and its extensions can be

used the way I need.

This will all be used only within my network sites. I do not intend to
allow users to autheticate with external OpenID providers, nor I want
other sites to use my OpenID provider to authenticate in other sites.

Since this is meant for use restricted to my sites, I could invent a
proprietary protocol, but I thought it was better to not reinvent the 
wheel.


I will develop all the necessary components to implement the OpenID
provider and consumers with the needed extensions. Actually the consumer
component is mostly done.

I was moving to the OpenID provider component when I noticed this thread
of using oAuth 2 for identity. So now I wonder if I am in the right
path? Shall I keep doing it with OpenID or shall I do it with oAuth 2?
Can anybody please shed some light so I can make the best decision?

--

Regards,
Manuel Lemos

Find and post PHP jobs
http://www.phpclasses.org/jobs/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs


Alex Barth
http://www.developmentseed.org/blog
tel (202) 250-3633




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



--
Nat Sakimura

このメールには、本来の宛先の方のみに限定された機密情報が含まれている場
合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメー
ルを削除してくださいますようお願い申し上げます。
PLEASE READ：This e-mail is confidential and intended for the named re
cipient only. If you are not an intended recipient, please notify the
sender and delete this e-mail.


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

Building identity on top of OAuth 2.0? (TAKE 2)

[Nat Sakimura]

So, while David's "OpenID Connect" straw man has bunch of interesting
properties,
there has been substantial work done in parallel in OpenID Foundation's own
Working Group.

It is called "Artifact Binding", and is almost ready to go.

The spec is at http://bitbucket.org/openid/ab/ (web readable copy is at
http://www.sakimura.org/specs/ab/ ).

Since a formal spec is not necessarily approachable, I have blogged about it
at 
http://www.sakimura.org/en/modules/wordpress/openid-ab-and-attributes-openid-connect/

I have even implemented it :)

Talk to you guys later at IIW.

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Draft OpenID v.Next Discovery working group charter

[Nat Sakimura]

Hmmm. So, what is your point?


On Thu, Apr 15, 2010 at 2:07 PM, Phillip Hallam-Baker  wrote:
> 404 Not Found.
>
> When the Web was first proposed, the thing the network hypertext
> community could not get their heads around was that Tim's 'scruffy'
> links were better than the database backed schemes they used to assure
> consistency.
>
> The 'unreliability' of delegation in email is both a benefit and a
> problem depending on what you are trying to achieve.
>
> When I left VeriSign my email address was disabled. But I can still
> log into sites as pba...@verisign.com as the credentials are
> maintained locally. So the lack of effective federation means that an
> authenticator that should fail does not.
>
> In the context of f...@extortion.com, Fred could in theory invest a
> huge amount of time and effort building up his reputation tied to a
> name he does not own and then find that he has no recourse when
> extortion.com raises rates on him.
>
>
> This is why the question of what gives a registry of names stability
> is a very complex problem. It is a very easy problem to solve if you
> just wish away all the problems.
>
> RealNames and AOL both attempted to establish naming schemes for the
> online world. Both ultimately suffered from the fact that businesses
> know about the fred.extortion.com problem and don't want to invest
> their advertising dollars building up a name they do not own.
>
> The only cases where these systems seem to succeed is when nobody is
> really aware of the political issues that they raise. DNS succeeded
> for one simple reason: it was considered to be a temporary research
> facility. There were two directory schemes bid by the NSF, Network
> Solutions got the tiny contract for the piddly testbed. Everyone else
> was bidding for the X.500 directory where the real money was going to
> be...
>
> ICANN is easy to take pot shots at - and I do quite frequently. But
> the one fact that made agreement on the ICANN charter possible was the
> fact that the DNS already existed and had several million names
> registered already. There was nothing to be achieved by simply
> filibustering the creation process. I am seeing other registry designs
> being proposed where that is not the case, and we now have governments
> saying that they would rather see no registry established than one
> that is under 'foreign domination'.
>
> Simply introducing an additional layer of indirection does not solve
> this particular problem. Its like cloud computing, drawing a picture
> of your server running in a cloud somewhere does not mean that the
> issues of physical security, power, cooling etc. can be ignored, they
> still have to be dealt with by someone.
>
>
> On Thu, Apr 15, 2010 at 12:37 AM, Nat Sakimura  wrote:
>> I suppose we need to define "OpenID identifiers" in the charter
>> proposal a little more.
>>
>> Specifically, I would like the discovery process to find a
>> non-reassignable identifier.
>> Otherwise, delegation would not work reliably etc.
>>
>> See: 
>> http://www.sakimura.org/en/modules/wordpress/identity-loss-with-openid-20/
>> for
>> some additional thought/discussion.
>>
>> =nat
>>
>> On Wed, Apr 14, 2010 at 4:30 AM, Mike Jones  
>> wrote:
>>> What follows is a draft charter for the OpenID v.Next Discovery working
>>> group.  This is one of 5 related charters for v.Next working groups to be
>>> formed to be discussed here, per my previous message.  Feedback is welcome,
>>> as are potential working group participants.
>>>
>>>
>>>
>>>     -- Mike
>>>
>>>
>>>
>>> (a)  Charter.
>>>
>>> (i)   WG name:  OpenID v.Next Discovery.
>>>
>>> (ii)  Purpose:  Produce a discovery specification or family of discovery
>>> specifications for OpenID v.Next that address the limitations and drawbacks
>>> present in the OpenID 2.0 discovery facilities that limit OpenID’s
>>> applicability, adoption, usability, privacy, and security.  Specific goals
>>> are:
>>>
>>> · enable discovery for OpenID identifiers, including those utilizing
>>> e-mail address syntax and those that are URLs,
>>>
>>> · enable discovery of features supported by OpenID v.Next OpenID
>>> Providers and Relying Parties,
>>>
>>> · enable discovery of attributes about OpenID v.Next OPs and RPs,
>>> including, but limited to visual logos and human-readable site names,
>>>
>

Re: Draft OpenID v.Next Discovery working group charter

[Nat Sakimura]

I suppose we need to define "OpenID identifiers" in the charter
proposal a little more.

Specifically, I would like the discovery process to find a
non-reassignable identifier.
Otherwise, delegation would not work reliably etc.

See: http://www.sakimura.org/en/modules/wordpress/identity-loss-with-openid-20/
for
some additional thought/discussion.

=nat

On Wed, Apr 14, 2010 at 4:30 AM, Mike Jones  wrote:
> What follows is a draft charter for the OpenID v.Next Discovery working
> group.  This is one of 5 related charters for v.Next working groups to be
> formed to be discussed here, per my previous message.  Feedback is welcome,
> as are potential working group participants.
>
>
>
>     -- Mike
>
>
>
> (a)  Charter.
>
> (i)   WG name:  OpenID v.Next Discovery.
>
> (ii)  Purpose:  Produce a discovery specification or family of discovery
> specifications for OpenID v.Next that address the limitations and drawbacks
> present in the OpenID 2.0 discovery facilities that limit OpenID’s
> applicability, adoption, usability, privacy, and security.  Specific goals
> are:
>
> · enable discovery for OpenID identifiers, including those utilizing
> e-mail address syntax and those that are URLs,
>
> · enable discovery of features supported by OpenID v.Next OpenID
> Providers and Relying Parties,
>
> · enable discovery of attributes about OpenID v.Next OPs and RPs,
> including, but limited to visual logos and human-readable site names,
>
> · enable discovery supporting a spectrum of clients, including
> passive clients per current usage, thin active clients, and active clients
> with OP functionality,
>
> · enable discovery supporting authentication to and use of
> attributes by non-browser applications,
>
> · seamlessly integrate with and complement the other OpenID v.Next
> specifications.
>
>     Compatibility with OpenID 2.0 is an explicit non-goal for this
> work.
>
> (iii) Scope:  Produce a next generation OpenID discovery specification
> or specifications, consistent with the purpose statement.
>
> (iv) Proposed List of Specifications:  OpenID v.Next Discovery and
> possibly related specifications.
>
> (v)  Anticipated audience or users of the work:  Implementers of OpenID
> Providers, Relying Parties, Active Clients, and non-browser applications
> utilizing OpenID.
>
> (vi) Language in which the WG will conduct business:  English.
>
> (vii)    Method of work:  E-mail discussions on the working group mailing
> list, working group conference calls, and face-to-face meetings at the
> Internet Identity Workshop and OpenID summits.
>
> (viii)  Basis for determining when the work of the WG is completed:  Work
> will not be deemed to be complete until there is a consensus that the
> resulting protocol specification or family of specifications fulfills the
> working group goals.  Additional proposed changes beyond that initial
> consensus will be evaluated on the basis of whether they increase or
> decrease consensus within the working group.  The work will be completed
> once it is apparent that maximal consensus on the draft has been achieved,
> consistent with the purpose and scope.
>
> (b)  Background Information.
>
> (i)   Related work being done in other WGs or organizations:  OpenID
> Authentication 2.0 and related specifications, including Yadis 1.0.  OAuth
> and OAuth WRAP.  XRDS, XRD, and WebFinger.
>
> (ii)  Proposers:
>
> Allen Tom, a...@yahoo-inc.com, Yahoo! (co-chair)
>
> Michael B. Jones, m...@microsoft.com, Microsoft (co-chair)
>
> John Bradley, ve7...@ve7jtb.com, independent
>
> Additional proposers to be added here
>
> (iii) Anticipated Contributions:  None.
>
>
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [WRAP] Wrap Artifact Binding/Mobile Profile

[Nat Sakimura]

FYI, the artifact binding ML is also ready. I have set up a repository at
http://bitbucket.org/openid/ab/changeset/b5542243e694/

One of the thing that I would like to discuss is whether we want to preserve
openid namespace etc. for the artifact binding
(since it is openid wg, I presume so) or move to wrap_ namespace.

The other thing that I would like to know/discuss is whether it is possible
to push the profile I described at

http://www.sakimura.org/en/modules/wordpress/oauth-wrap-mobile-web-app-profile/

=nat

On Thu, Feb 18, 2010 at 4:31 AM, Allen Tom  wrote:

>  I’ll be at the OpenID summit on April 5th.
>
> Allen
>
>
> On 2/17/10 7:36 AM, "Nat Sakimura"  wrote:
>
> As long as some bad thing does not happen in the current project that ends
> on March 31, I would.
>
> =nat
>
> On Thu, Feb 18, 2010 at 12:26 AM, John Bradley 
> wrote:
>
> Are you going to the openID summit Apr 5.   I am trying to decide if I can
> afford to fly back to the US for that.
>
> John B.
>
> On 2010-02-17, at 5:50 AM, Nat Sakimura wrote:
>
> Sorry but I cannot travel across the pacific this time for RSA ...
>
> Shall we have a con-call or something?
>
> =nat
>
> On Wed, Feb 17, 2010 at 3:24 PM, Allen Tom  wrote:
>
> I'm up for meeting in person at RSA or sooner to discuss.
>
> Allen
>
>
>
> On 2/16/10 7:31 AM, "John Bradley"  wrote:
>
> >
> > I am going to be at RSA if Nat is going perhaps we can get together there
> > before the openID summit the following month.
> >
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Please register to the Artifact Binding ML

[Nat Sakimura]

Hi.

The Artifact Binding WG mailing list is up.
Please register to it through
http://lists.openid.net/mailman/listinfo/openid-specs-ab

Cheers,

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Please register to the AX1.1 ML

[Nat Sakimura]

Hi.

Please subscribe yourselves to AX1.1 mailing list if you are a member of the
Working Group.

Registration page is:
http://lists.openid.net/mailman/listinfo/openid-specs-ax

Cheers,

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [WRAP] Name space and prefix - OpenID Harmonization

[Nat Sakimura]

Actually, that was because PHP variables does not allow '.' to be in it ...

On Tue, Mar 2, 2010 at 10:07 AM, Nat Sakimura  wrote:

> Goodness...
>
> Then what would be a good character for a delimiter?
> Or do we just use '_' for it and stop using '_' for the readability?
>
> =nat
>
>
> On Tue, Mar 2, 2010 at 9:26 AM, Joseph Smarr  wrote:
>
>> FYI, one reason OAuth/WRAP use _ instead of . is that PHP (stupidly)
>> converts all . to _ in query var names, so it's just easier not to fight
>> that, esp when you have to compute signatures. So if we're naming any new
>> params, I'd strongly argue for _ over . as the delimiter. Yes it's dumb, but
>> PHP is not going away any time soon, so this is the clear pragmatic choice.
>> js
>>
>> On Thu, Feb 25, 2010 at 8:22 PM, Nat Sakimura  wrote:
>>
>>>
>>>
>>> On Fri, Feb 26, 2010 at 11:55 AM, Dick Hardt wrote:
>>>
>>>>
>>>> On 2010-02-25, at 4:11 PM, Nat Sakimura wrote:
>>>>
>>>> Hi
>>>>
>>>> This may have come up earlier but ...
>>>>
>>>> I think Wrap should have a namespace / versioning syntax.
>>>> Invariably, it will evolve, and will require version number etc. so, it
>>>> seems better to me to have one from the beginning.
>>>>
>>>> e.g.,
>>>>
>>>> wrap_ns=http://whatever/wrap/1.0
>>>>> wrap_client_id ...
>>>>
>>>>
>>>> Versioning was discussed. I don't recall the details, but it was decided
>>>> it did not add value.
>>>>
>>>>
>>> I actually think it does.
>>> Perhaps not in the initial version, but in the future for sure.
>>> So, it is better to have it in the design from the beginning.
>>>
>>>
>>>>
>>>>
>>>> I would go further. Why is underscore '_' is used for the delimiter?
>>>> If we make it dot '.', it will improve the future compatibility with
>>>> OpenID.
>>>>
>>>>
>>>> Or OpenID could change to using '_'  :-)
>>>>
>>>
>>> If you use '_' as the namespace delimiter, then '_' should be disallowed
>>> in the parameter name, which is not the case right now.
>>>
>>>
>>>>
>>>>
>>>> So, we could do something like:
>>>>
>>>> openid.ns=http://whatever/wrap/1.0
>>>>
>>>> openid.client_id ...
>>>>
>>>>
>>>> The same applies for OpenID. For an unknown reason, though OpenID has
>>>> namespace so that we write:
>>>>
>>>> openid.ns= http://specs.openid.net/auth/2.0
>>>>
>>>>
>>>> the prefix "openid" is fixed. We should be able to change it like:
>>>>
>>>> wrap.ns=http://specs.openid.net/auth/2.0
>>>>
>>>>
>>>> Now, the third point.
>>>>
>>>> Could we not try to harmonize the variable names between the two specs?
>>>>
>>>> OpenID is in use widely, so it is kind of hard to change it,
>>>>
>>>>
>>>> Interesting assumption. At IIW we discussed OpenID v Next that was NOT
>>>> backward compatible. It would seem that there is an oppportunity to make
>>>> changes to OpenID as well as OAuth WRAP.
>>>>
>>>
>>> yes. The above also requires changes on the OpenID side, but I am seeing
>>> an opportunity to make the transition smoother.
>>>
>>>
>>>>
>>>> so I would request Wrap community to come closer.
>>>>
>>>>
>>>> WRAP followed OAuth, which has much broader adoption from what I know
>>>> than OpenID
>>>>
>>>>
>>> Arguably yes, but at the same time, 'wrap_' is not 'oauth_' ;-)
>>>
>>>>
>>>> IMHO, we should try to harmonize/unite instead of fragmenting.
>>>>
>>>>
>>>> Agreed, but perhaps the changes could happen in OpenID or a combination?
>>>>
>>>
>>> Definitely in combination.
>>>
>>> It is good that OpenID Foundation finally can start creating WGs again.
>>>
>>>
>>>>
>>>> -- Dick
>>>>
>>>> ___
>>>> specs mailing list
>>>> sp...@lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> http://www.sakimura.org/en/
>>> http://twitter.com/_nat_en
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "OAuth WRAP WG" group.
>>> To post to this group, send email to oauth-wrap...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> oauth-wrap-wg+unsubscr...@googlegroups.com
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/oauth-wrap-wg?hl=en.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "OAuth WRAP WG" group.
>> To post to this group, send email to oauth-wrap...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> oauth-wrap-wg+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/oauth-wrap-wg?hl=en.
>>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [WRAP] Name space and prefix - OpenID Harmonization

[Nat Sakimura]

Goodness...

Then what would be a good character for a delimiter?
Or do we just use '_' for it and stop using '_' for the readability?

=nat

On Tue, Mar 2, 2010 at 9:26 AM, Joseph Smarr  wrote:

> FYI, one reason OAuth/WRAP use _ instead of . is that PHP (stupidly)
> converts all . to _ in query var names, so it's just easier not to fight
> that, esp when you have to compute signatures. So if we're naming any new
> params, I'd strongly argue for _ over . as the delimiter. Yes it's dumb, but
> PHP is not going away any time soon, so this is the clear pragmatic choice.
> js
>
> On Thu, Feb 25, 2010 at 8:22 PM, Nat Sakimura  wrote:
>
>>
>>
>> On Fri, Feb 26, 2010 at 11:55 AM, Dick Hardt wrote:
>>
>>>
>>> On 2010-02-25, at 4:11 PM, Nat Sakimura wrote:
>>>
>>> Hi
>>>
>>> This may have come up earlier but ...
>>>
>>> I think Wrap should have a namespace / versioning syntax.
>>> Invariably, it will evolve, and will require version number etc. so, it
>>> seems better to me to have one from the beginning.
>>>
>>> e.g.,
>>>
>>> wrap_ns=http://whatever/wrap/1.0
>>>> wrap_client_id ...
>>>
>>>
>>> Versioning was discussed. I don't recall the details, but it was decided
>>> it did not add value.
>>>
>>>
>> I actually think it does.
>> Perhaps not in the initial version, but in the future for sure.
>> So, it is better to have it in the design from the beginning.
>>
>>
>>>
>>>
>>> I would go further. Why is underscore '_' is used for the delimiter?
>>> If we make it dot '.', it will improve the future compatibility with
>>> OpenID.
>>>
>>>
>>> Or OpenID could change to using '_'  :-)
>>>
>>
>> If you use '_' as the namespace delimiter, then '_' should be disallowed
>> in the parameter name, which is not the case right now.
>>
>>
>>>
>>>
>>> So, we could do something like:
>>>
>>> openid.ns=http://whatever/wrap/1.0
>>>
>>> openid.client_id ...
>>>
>>>
>>> The same applies for OpenID. For an unknown reason, though OpenID has
>>> namespace so that we write:
>>>
>>> openid.ns= http://specs.openid.net/auth/2.0
>>>
>>>
>>> the prefix "openid" is fixed. We should be able to change it like:
>>>
>>> wrap.ns=http://specs.openid.net/auth/2.0
>>>
>>>
>>> Now, the third point.
>>>
>>> Could we not try to harmonize the variable names between the two specs?
>>>
>>> OpenID is in use widely, so it is kind of hard to change it,
>>>
>>>
>>> Interesting assumption. At IIW we discussed OpenID v Next that was NOT
>>> backward compatible. It would seem that there is an oppportunity to make
>>> changes to OpenID as well as OAuth WRAP.
>>>
>>
>> yes. The above also requires changes on the OpenID side, but I am seeing
>> an opportunity to make the transition smoother.
>>
>>
>>>
>>> so I would request Wrap community to come closer.
>>>
>>>
>>> WRAP followed OAuth, which has much broader adoption from what I know
>>> than OpenID
>>>
>>>
>> Arguably yes, but at the same time, 'wrap_' is not 'oauth_' ;-)
>>
>>>
>>> IMHO, we should try to harmonize/unite instead of fragmenting.
>>>
>>>
>>> Agreed, but perhaps the changes could happen in OpenID or a combination?
>>>
>>
>> Definitely in combination.
>>
>> It is good that OpenID Foundation finally can start creating WGs again.
>>
>>
>>>
>>> -- Dick
>>>
>>> ___
>>> specs mailing list
>>> sp...@lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>> http://twitter.com/_nat_en
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "OAuth WRAP WG" group.
>> To post to this group, send email to oauth-wrap...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> oauth-wrap-wg+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/oauth-wrap-wg?hl=en.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "OAuth WRAP WG" group.
> To post to this group, send email to oauth-wrap...@googlegroups.com.
> To unsubscribe from this group, send email to
> oauth-wrap-wg+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/oauth-wrap-wg?hl=en.
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [WRAP] Name space and prefix - OpenID Harmonization

[Nat Sakimura]

On Fri, Feb 26, 2010 at 11:55 AM, Dick Hardt  wrote:

>
> On 2010-02-25, at 4:11 PM, Nat Sakimura wrote:
>
> Hi
>
> This may have come up earlier but ...
>
> I think Wrap should have a namespace / versioning syntax.
> Invariably, it will evolve, and will require version number etc. so, it
> seems better to me to have one from the beginning.
>
> e.g.,
>
> wrap_ns=http://whatever/wrap/1.0
>> wrap_client_id ...
>
>
> Versioning was discussed. I don't recall the details, but it was decided it
> did not add value.
>
>
I actually think it does.
Perhaps not in the initial version, but in the future for sure.
So, it is better to have it in the design from the beginning.


>
>
> I would go further. Why is underscore '_' is used for the delimiter?
> If we make it dot '.', it will improve the future compatibility with
> OpenID.
>
>
> Or OpenID could change to using '_'  :-)
>

If you use '_' as the namespace delimiter, then '_' should be disallowed in
the parameter name, which is not the case right now.


>
>
> So, we could do something like:
>
> openid.ns=http://whatever/wrap/1.0
>
> openid.client_id ...
>
>
> The same applies for OpenID. For an unknown reason, though OpenID has
> namespace so that we write:
>
> openid.ns= http://specs.openid.net/auth/2.0
>
>
> the prefix "openid" is fixed. We should be able to change it like:
>
> wrap.ns=http://specs.openid.net/auth/2.0
>
>
> Now, the third point.
>
> Could we not try to harmonize the variable names between the two specs?
>
> OpenID is in use widely, so it is kind of hard to change it,
>
>
> Interesting assumption. At IIW we discussed OpenID v Next that was NOT
> backward compatible. It would seem that there is an oppportunity to make
> changes to OpenID as well as OAuth WRAP.
>

yes. The above also requires changes on the OpenID side, but I am seeing
an opportunity to make the transition smoother.


>
> so I would request Wrap community to come closer.
>
>
> WRAP followed OAuth, which has much broader adoption from what I know than
> OpenID
>
>
Arguably yes, but at the same time, 'wrap_' is not 'oauth_' ;-)

>
> IMHO, we should try to harmonize/unite instead of fragmenting.
>
>
> Agreed, but perhaps the changes could happen in OpenID or a combination?
>

Definitely in combination.

It is good that OpenID Foundation finally can start creating WGs again.


>
> -- Dick
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Name space and prefix - OpenID Harmonization

[Nat Sakimura]

Hi

This may have come up earlier but ...

I think Wrap should have a namespace / versioning syntax.
Invariably, it will evolve, and will require version number etc. so, it
seems better to me to have one from the beginning.

e.g.,

wrap_ns=http://whatever/wrap/1.0
wrap_client_id ...


I would go further. Why is underscore '_' is used for the delimiter?
If we make it dot '.', it will improve the future compatibility with OpenID.

So, we could do something like:

openid.ns=http://whatever/wrap/1.0

openid.client_id ...


The same applies for OpenID. For an unknown reason, though OpenID has
namespace so that we write:

openid.ns= http://specs.openid.net/auth/2.0


the prefix "openid" is fixed. We should be able to change it like:

wrap.ns=http://specs.openid.net/auth/2.0


Now, the third point.

Could we not try to harmonize the variable names between the two specs?

OpenID is in use widely, so it is kind of hard to change it, so I would
request Wrap community to come closer.
For example, instead of 'callback', why cannot we use 'return_to'? So, the
Wrap Web App Profile request
will become like:

wrap.ns=http://whatever/wrap/1.0
wrap.return_to=http://example.com/callback_url
wrap.client_state=opaque_string_to_maintain_state
wrap.client_id=the_client_identifier

If we do that, rewriting openid with wrap becomes much more straightforward,
e.g.,

openid.ns=http://specs.openid.net/auth/2.x
openid.return_to=http://example.com/callback_url
openid.mode=checkid_setup
openid.client_id=client_identifier
openid.client_state=opaque_string_to_maintain_state
openid.claimed_id=http://example.com/alice
openid.identity=http://example.com/user/alice
openid.assoc_handle={some_assoc_handle}


where client_id and client_state is a new introduction to openid 2.x and
openid.mode and going forward will be "additional parameters" from the
point of view of Wrap.

IMHO, we should try to harmonize/unite instead of fragmenting.

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: resolvable spec URIs

[Nat Sakimura]

Thanks very much Will,

This is what we needed for a long time.

Inline:

(2010/02/23 10:26), Will Norris wrote:

just a heads up that I've added a few mod_rewrite rules to openid.net so that 
the following spec URIs actually redirect to their respective spec documents:
   http://openid.net/signon/1.1
   http://openid.net/sreg/1.0
   http://openid.net/sreg/1.1
   http://openid.net/srv/ax/1.0


I'm not sure what to do about the URI for OpenID Auth 1.0, because there is no 
nice HTML version of the spec that I can find.  Any suggestions?  Just redirect 
it to the 1.1 spec, since it's effectively identical?
   http://openid.net/signon/1.0
   

I think, redirecting to 1.1 spec is a sensible thing to do.


And the following URIs are use sub-domains, so I can't set them up.  If we could get someone at OSL 
to setup CNAMEs and Apache virtual hosts for "specs.openid.net" and 
"schemas.openid.net", I'll get these setup as well:
   http://specs.openid.net/auth/2.0
   http://specs.openid.net/extensions/pape/1.0
   http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
   http://schemas.openid.net/pape/policies/2007/06/multi-factor
   http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical

Are there any others that I missed?
   

Not that I recall.

On the side note, we need to set up a spec URL creation rule, I suppose.
I prefer short ones :-)


-will

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



--
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

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

Re: [OIDFSC] OpenID Artifact Binding Working Group Proposal

[Nat Sakimura]

Hi Spec'ers,

Under the newly approved IPR
policy
,
if the specs council does not makea recommendation within 15 days, the
working group is automatically approved. The Artifact Binding WG proposal
was made on Feb. 5, and falls under this category. Thus, the Artifact
Binding WG is created.

Next step would be, as usual, the creation of the repository, ML, and
collection of the Contribution Agreements.

Best,

=nat
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [WRAP] Wrap Artifact Binding/Mobile Profile

[Nat Sakimura]

As long as some bad thing does not happen in the current project that ends
on March 31, I would.

=nat

On Thu, Feb 18, 2010 at 12:26 AM, John Bradley wrote:

> Are you going to the openID summit Apr 5.   I am trying to decide if I can
> afford to fly back to the US for that.
>
> John B.
>
> On 2010-02-17, at 5:50 AM, Nat Sakimura wrote:
>
> Sorry but I cannot travel across the pacific this time for RSA ...
>
> Shall we have a con-call or something?
>
> =nat
>
> On Wed, Feb 17, 2010 at 3:24 PM, Allen Tom  wrote:
>
>> I'm up for meeting in person at RSA or sooner to discuss.
>>
>> Allen
>>
>>
>>
>> On 2/16/10 7:31 AM, "John Bradley"  wrote:
>>
>> >
>> > I am going to be at RSA if Nat is going perhaps we can get together
>> there
>> > before the openID summit the following month.
>> >
>>
>> _______
>> specs mailing list
>> sp...@lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
>  ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [WRAP] Wrap Artifact Binding/Mobile Profile

[Nat Sakimura]

Sorry but I cannot travel across the pacific this time for RSA ...

Shall we have a con-call or something?

=nat

On Wed, Feb 17, 2010 at 3:24 PM, Allen Tom  wrote:

> I'm up for meeting in person at RSA or sooner to discuss.
>
> Allen
>
>
>
> On 2/16/10 7:31 AM, "John Bradley"  wrote:
>
> >
> > I am going to be at RSA if Nat is going perhaps we can get together there
> > before the openID summit the following month.
> >
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [WRAP] Wrap Artifact Binding/Mobile Profile

[Nat Sakimura]

+1

On Wed, Feb 17, 2010 at 7:44 AM, John Bradley  wrote:

> I agree that there is no practical use for the association handle if we
> have a per artifact secret.
>
> That is why it may be useful to think of artefact as something not
> dependent on the existing redirect binding.
>
> John B.
> On 2010-02-16, at 6:34 PM, Allen Tom wrote:
>
> > Hi John -
> >
> > I was not suggesting that everyone use Artifact binding - presumably the
> OP
> > will indicate that it supports Artifact binding in its discovery
> document,
> > and it'll be up to the RP initiate the artifact request.
> >
> > Also, regarding my previous proposal to ditch the association request for
> > artifact binding - I concede that artifact binding is orthogonal to
> > associations.
> >
> > However, if one of the goals of artifact binding is to shorten the size
> of
> > the requests/responses, then eliminating the association handle would be
> > consistent with this goal.
> >
> > Allen
> >
> > On 2/16/10 1:09 PM, "John Bradley"  wrote:
> >
> >> We can't force everyone to do artifact.  We will still need to support
> >> associations in RP's.
> >> We cant just ditch the concept completely.
> >>
> >
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [WRAP] Wrap Artifact Binding/Mobile Profile

[Nat Sakimura]

On Tue, Feb 16, 2010 at 1:34 PM, Allen Tom  wrote:

>  HI Nat -
>
> Why is association expensive? It should be no worse than issuing an
> artifact. I guess it depends on the underlying implementation.
>

AES or SHA1 is computationally much cheaper than DH, I think.

If the main reason for the combining association and artifact request is to
save round-trips, it does not save so much.
Suppose Association is done only once in a day, and there are 1 million
authentication in a day, you are saving only
0.001 round trip per authentication, or equivalently, one round trip per
day per OP-RP pair.

In return, you have sacrificed

1) Computational resource (both CPU and storage since now you have to store
the association for every user instead of just OP-RP pair)
2) Ability to sign the artifact request
3) You cannot use different artifact in the request and response, making it
rather difficult to implement stateless Artifact mode.

Breno - please elaborate on 3). Briefly stating, if request and response
artifacts are allowed to be different, the OP can encode all the information
into the artifact in a proprietary fashion so that OP can achieve the
RESTful artifact mode.

See: http://lists.openid.net/pipermail/openid-specs/2009-August/005939.html
and http://iiw.idcommons.net/OpenID_Artifact_Binding

=nat


>
> The point of the association is to eliminate the extra round trip (aka dumb
> mode) - however artifact mode by definition requires an extra round trip. I
> have not thought about this too deeply, however I don’t think the
> association step adds anything when artifact binding is used.
>
> What is the point of having different request and response artifacts? I
> don’t think that’s necessary.
>
> At least in Yahoo’s case, we can probably get by with
> artifacts/associations that are well under 255 bytes.  Our OAuth Request
> Tokens are only 8 bytes, and that’s large enough.
>
> Allen
>
>
>
>
> On 2/12/10 10:04 PM, "Nat Sakimura"  wrote:
>
> Hi Allen,
>
> That can be done, but there are a few things to be considered as well.
>
> 1) Association is a rather expensive operation. We might not want to do it
> with
> every authentication request.
> 2) Breno wanted to have something like 400 bytes or so to achieve
> statelessness in  255bytes restriction may be too short for him.
> 3) Breno (and you I think) wanted to have the request artifact and response
> artifact different.
> 3) This would probably mean that we need to touch the core library in many
> case and arguably has larger impact - which means that we may end up with
> more adoption friction. (BTW, we actually wrote test code in Java, Python,
> PHP, and Ruby to see if the draft can be implemented without touching the
> core library.)
> 4) In the longer term, I am suspecting that association might be
> disappearing (like it did in Wrap) so depending on it might not be a good
> idea.
>
> In fact, initially, I was thinking the same with you half a year ago, but
> after a while, I have abandoned the idea. Assuming that association happens
> once in every hundreds of authentication request, it just buys me 0.01 round
> trip per authentication request or less. It is going to be even less for a
> large provider. I could probably trade that round trip with the benefit
> gained from the above reasons. That's why I did not piggy back on the
> association.
>
> =nat
>
>
> On Sat, Feb 13, 2010 at 1:39 PM, Allen Tom  wrote:
>
> Hi Nat -
>
> As an optimization, can we combine the association request with the
> artifact request? In fact, why can’t the association handle *be* the
> artifact?
>
> For example, when the RP requests association, it can pass along all the
> request parameters that it normally would pass via the browser in the
> authentication request. The OP can then return the association
> handle/artifact along with the shared secret.
>
> The RP then redirects the user’s browser to the OP with the association
> handle. After the user authenticates, the OP redirects the browser back to
> the RP with the association handle.
>
> The RP then makes a direct server call back to the OP with the handle (and
> probably also the shared secret) to fetch the assertion.
>
> I think this scheme will save a couple round trips.
>
> Allen
>
>
>
>
>
> On 2/11/10 9:55 PM, "Nat Sakimura"  http://sakim...@gmail.com> > wrote:
>
> If you look at my manuscript of the Artifact Binding (
> http://www.sakimura.org/specs/ab/1.0 )
>
>
>
>   --
> You received this message because you are subscribed to the Google Groups
> "OAuth WRAP WG" group.
> To post to this group, send email to oauth-wrap...@googlegroups.com.
> To unsubscribe from this group, send e

Re: [WRAP] Wrap Artifact Binding/Mobile Profile

[Nat Sakimura]

Hi Allen,

That can be done, but there are a few things to be considered as well.

1) Association is a rather expensive operation. We might not want to do it
with
every authentication request.
2) Breno wanted to have something like 400 bytes or so to achieve
statelessness in  255bytes restriction may be too short for him.
3) Breno (and you I think) wanted to have the request artifact and response
artifact different.
3) This would probably mean that we need to touch the core library in many
case and arguably has larger impact - which means that we may end up with
more adoption friction. (BTW, we actually wrote test code in Java, Python,
PHP, and Ruby to see if the draft can be implemented without touching the
core library.)
4) In the longer term, I am suspecting that association might be
disappearing (like it did in Wrap) so depending on it might not be a good
idea.

In fact, initially, I was thinking the same with you half a year ago, but
after a while, I have abandoned the idea. Assuming that association happens
once in every hundreds of authentication request, it just buys me 0.01 round
trip per authentication request or less. It is going to be even less for a
large provider. I could probably trade that round trip with the benefit
gained from the above reasons. That's why I did not piggy back on the
association.

=nat


On Sat, Feb 13, 2010 at 1:39 PM, Allen Tom  wrote:

>  Hi Nat -
>
> As an optimization, can we combine the association request with the
> artifact request? In fact, why can’t the association handle *be* the
> artifact?
>

> For example, when the RP requests association, it can pass along all the
> request parameters that it normally would pass via the browser in the
> authentication request. The OP can then return the association
> handle/artifact along with the shared secret.
>
> The RP then redirects the user’s browser to the OP with the association
> handle. After the user authenticates, the OP redirects the browser back to
> the RP with the association handle.
>
> The RP then makes a direct server call back to the OP with the handle (and
> probably also the shared secret) to fetch the assertion.
>
> I think this scheme will save a couple round trips.
>
> Allen
>
>
>
>
>
> On 2/11/10 9:55 PM, "Nat Sakimura"  wrote:
>
> If you look at my manuscript of the Artifact Binding (
> http://www.sakimura.org/specs/ab/1.0 )
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [WRAP] Wrap Artifact Binding/Mobile Profile

[Nat Sakimura]

If you look at my manuscript of the Artifact Binding (
http://www.sakimura.org/specs/ab/1.0 ) , it is clear that the Artifact is
created and consumed by OP/AuthzServer and is opaque to RP/WebAppClient. It
has no restriction other than that it should be below 400 bytes. (NB: It is
much bigger than SAML's 30bytes limit).

Or, if you are talking about the Access Token in fig. 1 of
http://www.sakimura.org/en/modules/wordpress/oauth-wrap-mobile-web-app-profile/,
then, it is also completely opaque. It does not even have the size
limit.
Only the condition is that AuthzServer and Resource has the common
understanding of what it is.

=nat


On Thu, Feb 11, 2010 at 7:56 AM, John Bradley wrote:

> In principal it would work.  The only downside is that the artifact/token
> might be smaller if it were a simple SHA256 XORd with the association secret
> or something like that.
>
> I like the concept in principal if it doesn't compromise the ability to
> have a small response via GET.
>
> I had questions around the token format returned by the protected
> resource.(artifact resolution)
>
> John B.
>
> On 2010-02-10, at 7:27 PM, Allen Tom wrote:
>
> + [sp...@openid]
>
> Nat – this is exactly what I had in mind. In many ways Oauth and Oauth-WRAP
> are  similar to artifact binding – the user approves a token, which is then
> passed back to the RP via a browser redirect. The token is then used by the
> RP to make web service calls on the OP to access a Protected Resource.
>
> The token is kind of like an artifact, and the Protected Resource can be an
> OpenID assertion.
>
> Would we be able to combine the OpenID Artifact Binding Extension with
> OAuth WRAP? If so, that would be great.
>
> Allen
>
>
> On 2/8/10 7:29 PM, "Nat Sakimura"  wrote:
>
> Hi
>
> I was wondering if we could define an Artifact Binding/Mobile Profile for
> Wrap.
>
> The way I would do is pretty simple because Wrap Web App Profile is an
> Artifact Binding to some extent.
> Just send Verification Code Request directly from WebAppClient to
> AuthzServer
> and get an Artifact back and bring that to AuthzServer through UA.
> After PoP, another artifact is created at AuthzServer and
> it is brough back to the WebAppClient through UA redirect.
> Then, the verification Code Response can be obtained from AuthzServer
>  directly using the artifact.
> The rest is the same.
>
> I created an blog entry with pretty diagram at
>
> http://www.sakimura.org/en/modules/wordpress/oauth-wrap-mobile-web-app-profile/
>
> It may be easier to see the page instead of the above description.
>
> (Instead of using response artifact, Verification Code Response can be sent
> directly,
>  but then we would be introducing AuthzServer -> WebAppClient
> communication, which would have
>  some implication on firewall configuration.)
>
> For those of you who say that "Artifact is Complex", see the original Web
> App Profile here:
>
>
> http://www.sakimura.org/en/modules/wordpress/oauth-wrap-web-app-profile-summary/
>
> It is almost identical.
>
> Added value is that is is more "mobile" friendly, and is actually more
> secure if the
> Request Artifact and Response Artifact (wrap_verification_code) is
> generated cryptographically
> strongly.
>
> What would you think?
>
>  ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Artifact Types (was: Re: "openid." name space of KeyValue Form)

[Nat Sakimura]

If the usecase is real, I am all for it, but I am not sure why RP wants to
have a specific type of OP token. Could you elaborate a little more?

=nat

P.S., since we are talking about use cases etc., I am assuming it is still
safe to do this at s...@.

On Tue, Feb 9, 2010 at 10:22 AM, John Bradley wrote:

> I wasn't referring to the artifact itself.  I agree that should be opaque.
>
> I am talking about the token that is returned from the direct
> communication.
>
> That needs to be encrypted.
>
> Encrypting it with the symmetric key works as a basic option.
>
> The RP needs some way to signal the OP what token type it wants to get.
>
> EG plain,  plane + symetric,  plane + asymetric,  jason + asymetric etc.
>
> I don't know that overloading PAPE is the best thing.
>
> John B.
>
>
> On 2010-02-08, at 10:14 PM, Nat Sakimura wrote:
>
>  I changed the Subject to fit the discussion.
>
> It is not me who decides what but the WG so this is just my personal
> opinion,
> but to me, Artifact is an opaque string to the RP. i.e., it can be
> anything, and it does not matter.
> It is up to the OP to create and consume artifact. Only requirement in the
> contributed
> document is that it has to be constructed partly from RFC1750 pseudorandom
> number sequence
> to thwart guessing. Since it is OP who creates and consume it, the OP can
> encrypt it by
> his symmetric key.
>
> If you wanted to express whether it was encrypted or not, there are two
> ways of doing it, IMHO.
>
> One is as you suggested, to do it in the AB itself. In this case, I would
> support the idea of
> arbitrary token types.
>
> The other is to do it through PAPE.
>
> If it were just for LoA, I feel that keeping the Artifact completely opaque
> and
> using PAPE for LoA purpose is the right way to do.
>
> =nat
>
> (2010/02/08 23:59), John Bradley wrote:
>
> The Artifact binding will have to support a encrypted token type or types
> if it is going to be LoA 2+ compliant.
>
>  The question is if you are going to support 2 token types,  should it be
> generalized to support arbitrary token types.
>
>  John B.
>  On 2010-02-08, at 8:16 AM, Nat Sakimura wrote:
>
> Hmmm. OK. Got it.
>
>  So, it probably is the topic that we might want to revisit when we
> introduce new response type like JSON in v.next, if we ever do, I suppose.
> There may be some cases that we might want to respond to the request at
> once. (Do not know if there would be.)
>
>  Thanks.
>
>  =nat
>
> On Mon, Feb 8, 2010 at 3:03 PM, Will Norris  wrote:
>
>>
>> On Feb 7, 2010, at 8:45 PM, Nat Sakimura wrote:
>>
>> > (2010/02/08 10:50), Will Norris wrote:
>> >> I've never thought of the "openid." prefix as part of the parameter
>> name, even in URL form encoded messages... it's simply a namespace prefix to
>> ensure URL parameters don't collide.  It's completely unnecessary in KVF
>> encoded messages, and would add nothing but extra size to the payload.
>> >
>> > That's what I was thinking. But after Hideki's message, I started to
>> doubt that a bit.
>> > Currently, we only use Direct Response in a very limited way: (1)
>> association response and (2) direct verification. In both case, we actually
>> only send openid.* parameters in the request, so we do not need any name
>> space qualifier in the response.
>>
>>  Not necessarily.  What about when the OpenID server's URL is "
>> http://example.com/?service=openid"; ?  This was actually the case for the
>> WordPress OpenID plugin for a long time, and is still true for certain
>> deployments, I believe.  You can't make any assumptions about what the base
>> URL will be, or what additional parameters may be present, hence why the
>> "openid." is certainly necessary in those cases.
>>
>>
>> > If we do not send anything but openid parameters on the request,
>> openid.* as a part of url is redundant.
>> > If there is value in having openid.* in the request, then that is to
>> send parameters in other name-spaces, in which case, the response may
>> include other parameters as well, and we need name-space qualifier.
>>
>>  allowing non-OpenID parameters in a direct response has never been a
>> design goal, nor do I believe that it should be.  KVF encoding is a new
>> format defined by the OpenID spec, so it is perfectly acceptable to state
>> that it is only for OpenID related parameters.  This is not the case for URL
>> parameters.
>>  _______
>> specs mailing list
>&g

Artifact Types (was: Re: "openid." name space of KeyValue Form)

[Nat Sakimura]

I changed the Subject to fit the discussion.

It is not me who decides what but the WG so this is just my personal 
opinion,
but to me, Artifact is an opaque string to the RP. i.e., it can be 
anything, and it does not matter.
It is up to the OP to create and consume artifact. Only requirement in 
the contributed
document is that it has to be constructed partly from RFC1750 
pseudorandom number sequence
to thwart guessing. Since it is OP who creates and consume it, the OP 
can encrypt it by

his symmetric key.

If you wanted to express whether it was encrypted or not, there are two 
ways of doing it, IMHO.


One is as you suggested, to do it in the AB itself. In this case, I 
would support the idea of

arbitrary token types.

The other is to do it through PAPE.

If it were just for LoA, I feel that keeping the Artifact completely 
opaque and

using PAPE for LoA purpose is the right way to do.

=nat

(2010/02/08 23:59), John Bradley wrote:
The Artifact binding will have to support a encrypted token type or 
types if it is going to be LoA 2+ compliant.


The question is if you are going to support 2 token types,  should it 
be generalized to support arbitrary token types.


John B.
On 2010-02-08, at 8:16 AM, Nat Sakimura wrote:


Hmmm. OK. Got it.

So, it probably is the topic that we might want to revisit when we 
introduce new response type like JSON in v.next, if we ever do, I 
suppose. There may be some cases that we might want to respond to the 
request at once. (Do not know if there would be.)


Thanks.

=nat

On Mon, Feb 8, 2010 at 3:03 PM, Will Norris <mailto:w...@willnorris.com>> wrote:



On Feb 7, 2010, at 8:45 PM, Nat Sakimura wrote:

> (2010/02/08 10:50), Will Norris wrote:
>> I've never thought of the "openid." prefix as part of the
parameter name, even in URL form encoded messages... it's simply
a namespace prefix to ensure URL parameters don't collide.  It's
completely unnecessary in KVF encoded messages, and would add
nothing but extra size to the payload.
>
> That's what I was thinking. But after Hideki's message, I
started to doubt that a bit.
> Currently, we only use Direct Response in a very limited way:
(1) association response and (2) direct verification. In both
case, we actually only send openid.* parameters in the request,
so we do not need any name space qualifier in the response.

Not necessarily.  What about when the OpenID server's URL is
"http://example.com/?service=openid"; ?  This was actually the
case for the WordPress OpenID plugin for a long time, and is
still true for certain deployments, I believe.  You can't make
any assumptions about what the base URL will be, or what
additional parameters may be present, hence why the "openid." is
certainly necessary in those cases.


> If we do not send anything but openid parameters on the
request, openid.* as a part of url is redundant.
> If there is value in having openid.* in the request, then that
is to send parameters in other name-spaces, in which case, the
response may include other parameters as well, and we need
name-space qualifier.

allowing non-OpenID parameters in a direct response has never
been a design goal, nor do I believe that it should be.  KVF
encoding is a new format defined by the OpenID spec, so it is
perfectly acceptable to state that it is only for OpenID related
parameters.  This is not the case for URL parameters.
___
specs mailing list
sp...@lists.openid.net <mailto:sp...@lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs




--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net <mailto:sp...@lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs



_______
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs
   



--
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

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

Re: "openid." name space of KeyValue Form

[Nat Sakimura]

Hmmm. OK. Got it.

So, it probably is the topic that we might want to revisit when we introduce
new response type like JSON in v.next, if we ever do, I suppose. There may
be some cases that we might want to respond to the request at once. (Do not
know if there would be.)

Thanks.

=nat

On Mon, Feb 8, 2010 at 3:03 PM, Will Norris  wrote:

>
> On Feb 7, 2010, at 8:45 PM, Nat Sakimura wrote:
>
> > (2010/02/08 10:50), Will Norris wrote:
> >> I've never thought of the "openid." prefix as part of the parameter
> name, even in URL form encoded messages... it's simply a namespace prefix to
> ensure URL parameters don't collide.  It's completely unnecessary in KVF
> encoded messages, and would add nothing but extra size to the payload.
> >
> > That's what I was thinking. But after Hideki's message, I started to
> doubt that a bit.
> > Currently, we only use Direct Response in a very limited way: (1)
> association response and (2) direct verification. In both case, we actually
> only send openid.* parameters in the request, so we do not need any name
> space qualifier in the response.
>
> Not necessarily.  What about when the OpenID server's URL is "
> http://example.com/?service=openid"; ?  This was actually the case for the
> WordPress OpenID plugin for a long time, and is still true for certain
> deployments, I believe.  You can't make any assumptions about what the base
> URL will be, or what additional parameters may be present, hence why the
> "openid." is certainly necessary in those cases.
>
>
> > If we do not send anything but openid parameters on the request, openid.*
> as a part of url is redundant.
> > If there is value in having openid.* in the request, then that is to send
> parameters in other name-spaces, in which case, the response may include
> other parameters as well, and we need name-space qualifier.
>
> allowing non-OpenID parameters in a direct response has never been a design
> goal, nor do I believe that it should be.  KVF encoding is a new format
> defined by the OpenID spec, so it is perfectly acceptable to state that it
> is only for OpenID related parameters.  This is not the case for URL
> parameters.
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: "openid." name space of KeyValue Form

[Nat Sakimura]

(2010/02/08 10:50), Will Norris wrote:
I've never thought of the "openid." prefix as part of the parameter 
name, even in URL form encoded messages... it's simply a namespace 
prefix to ensure URL parameters don't collide.  It's completely 
unnecessary in KVF encoded messages, and would add nothing but extra 
size to the payload.


That's what I was thinking. But after Hideki's message, I started to 
doubt that a bit.
Currently, we only use Direct Response in a very limited way: (1) 
association response and (2) direct verification. In both case, we 
actually only send openid.* parameters in the request, so we do not need 
any name space qualifier in the response. This led me to these question:


"Why are we putting openid.* in those request? / Why are we not putting 
openid.* to the response? "


If we do not send anything but openid parameters on the request, 
openid.* as a part of url is redundant.
If there is value in having openid.* in the request, then that is to 
send parameters in other name-spaces, in which case, the response may 
include other parameters as well, and we need name-space qualifier.




You certainly don't need to add the prefix to KVF message to have 
consistency within an OpenID library.  For example, in the Internet2 
library that logic is entirely encapsulated within the message encoder 
and decoder.  Compare URLFormCodec[0] to KeyValueFormCodec[1].  
Everywhere else in the library, all message are treated exactly the 
same, regardless of how they were encoded on the wire.
[0]: 
http://svn.middleware.georgetown.edu/view/java-openid/trunk/src/main/java/edu/internet2/middleware/openid/message/encoding/impl/URLFormCodec.java?view=markup 

[1]: 
http://svn.middleware.georgetown.edu/view/java-openid/trunk/src/main/java/edu/internet2/middleware/openid/message/encoding/impl/KeyValueFormCodec.java?view=markup 

No, we do not. I have never seen a library that puts openid.* in KVF. My 
curiosity after seeing Hideki's mail was not the current implementation 
issue but about the future consistency and a little bit of historical 
perspective.



On Feb 7, 2010, at 4:22 AM, Paul E. Jones wrote:

For use in Key-Value Form, I didn't see it as necessary when I 
implemented

the spec.  It seemed logical not the be there.

The only reason why one might want to use this is to include some 
kind of
non-standard information.  Is that something folks would want to 
encourage?
Anyway, changing the spec to have "openid." there now would break 
things, so

I would not recommend it unless there was a really good reason.

Paul


-Original Message-
From: openid-specs-boun...@lists.openid.net [mailto:openid-specs-
boun...@lists.openid.net] On Behalf Of Nat Sakimura
Sent: Monday, February 01, 2010 12:14 AM
To: openid-specs@lists.openid.net
Subject: Re: "openid." name space of KeyValue Form

Hmmm

That's a good question. The reason we put openid.* in the request and
response is that there may be other applications sharing the same
request/response. If so, it would be more consistent if we put openid.*
prefix to the keys of the direct response as well...

Is it just an oversight, or did it have a good reason for it?

=nat

(2010/02/01 13:49), nara hideki wrote:

Hello all,

I'm thinking of the good reason why "openid." name space to keys of
Key-Value Form Encoding used for direct responses is dropped.
I think that we MAY use "openid." name space.

I'm very happy if someone give me a good cue to understand the

reason.


Thanks in advance.

hdknr
_______
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs




--
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

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




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



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



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

Re: "openid." name space of KeyValue Form

[Nat Sakimura]

Hi Paul,

All the libraries that I know do not put openid. in KVF.
The current spec is written like that and it is the correct behavior.

Until Hideki's message, it never occurred to me.

I suppose Hideki's is asking the reasoning that we made this asymmetry 
in the URL encoding and KVF.


=nat

(2010/02/07 21:22), Paul E. Jones wrote:

For use in Key-Value Form, I didn't see it as necessary when I implemented
the spec.  It seemed logical not the be there.

The only reason why one might want to use this is to include some kind of
non-standard information.  Is that something folks would want to encourage?
Anyway, changing the spec to have "openid." there now would break things, so
I would not recommend it unless there was a really good reason.

Paul

   

-Original Message-
From: openid-specs-boun...@lists.openid.net [mailto:openid-specs-
boun...@lists.openid.net] On Behalf Of Nat Sakimura
Sent: Monday, February 01, 2010 12:14 AM
To: openid-specs@lists.openid.net
Subject: Re: "openid." name space of KeyValue Form

Hmmm

That's a good question. The reason we put openid.* in the request and
response is that there may be other applications sharing the same
request/response. If so, it would be more consistent if we put openid.*
prefix to the keys of the direct response as well...

Is it just an oversight, or did it have a good reason for it?

=nat

(2010/02/01 13:49), nara hideki wrote:
 

Hello all,

I'm thinking of the good reason why "openid." name space to keys of
Key-Value Form Encoding used for direct responses is dropped.
I think that we MAY use "openid." name space.

I'm very happy if someone give me a good cue to understand the
   

reason.
 

Thanks in advance.

hdknr
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

   


--
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

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

 


   



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

Re: [OIDFSC] OpenID Artifact Binding Working Group Proposal

[Nat Sakimura]

On Sat, Feb 6, 2010 at 1:07 AM, David Recordon  wrote:

> I'm really weary of making non-compatible protocol changes
> as separate efforts.  If this is going to be done then it should happen
> within the context of the main specification.


As JohnB mentioned, it is just an additional layer. If the RP supports only
the conventional one, it is fine.
If the RP supports it but if OP does not, the RP can find it out and falls
back to the POST binding.


>
> Personally I'm worried about the additional complexity given a relatively
> narrow group of implementors calling for the feature.
>

Could you kindly define what you mean by "relatively narrow"?
If you think it is only the proposers who wants this feature, you are
mistaken.
Also, from the implementation side, it is not that complex.

Frankly speaking, I think OpenID will die if we do not support this kind of
feature because it is not viable in the mobile world.


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


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: [OIDFSC] OpenID Artifact Binding Working Group Proposal

[Nat Sakimura]

On Sat, Feb 6, 2010 at 1:17 AM, John Bradley wrote:

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

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


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

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


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

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


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

;-)


>
> In this case I think people have proceeded independently because they could
> not get this WG started.
>
> I do think the WG needs to consider all of the design options for adding
> this.
>
> John B.
> On 2010-02-05, at 1:07 PM, David Recordon wrote:
>
> I'm really weary of making non-compatible protocol changes
> as separate efforts.  If this is going to be done then it should happen
> within the context of the main specification.
>
> Personally I'm worried about the additional complexity given a relatively
> narrow group of implementors calling for the feature.
>
> --David
>
> On Fri, Feb 5, 2010 at 4:01 PM, John Bradley wrote:
>
>> This creates a new direct message type.   I thought extensions were
>> extending the existing messages.
>>
>> It is probably a grey area.
>>
>> Other protocols consider this to be a separate protocol binding rather
>> than an extension of the redirect or POST binding.
>>
>> John B.
>>
>>
>> On 2010-02-05, at 12:23 PM, David Recordon wrote:
>>
>> Hey Nat,
>> Shouldn't this be considered an extension?
>>
>> --David
>>
>> On Fri, Feb 5, 2010 at 2:54 PM, Nat Sakimura  wrote:
>>
>>> *OpenID Artifact Binding Working Group*
>>> --
>>>  *Charter Proposal*
>>> In accordance with the OpenID Foundation IPR policies and procedures this
>>> note proposes the formation of a new working group chartered to produce an
>>> OpenID specification. As per Section 4.1 of the Policies, the proposed
>>> charter is below.
>>> --
>>>  *I. Name*
>>> Artifact Binding Working Group (AB)
>>> --
>>>  *II. Statement of Purpose*
>>> Produce a binding of OpenID requests and response (assertion) that uses
>>> direct communication for main payload and indirect communication for a small
>>> reference data called Artifact to cope with long URL limits experienced by
>>> man
>>> --
>>>  *III. Scope*
>>> Create the Artifact Binding to support the identified needs. Currently
>>> identified:
>>>
>>>- Cope with long url problem, especially for mobile browsers.
>>>- Cope with the security problems of non-encrypted payload to go
>>>through the user agents which may act as a man-in-the-middle.
>>>
>>> --
>>>  *IV. Specifications*
>>> OpenID Artifact Binding 1.0
>>> --
>>>  *V. Anticipated audience*
>>> All those interested in using OpenID in mobile and other constrained
>>>

Re: "openid." name space of KeyValue Form

[Nat Sakimura]

Hmmm

That's a good question. The reason we put openid.* in the request and 
response is that there may be other applications sharing the same 
request/response. If so, it would be more consistent if we put openid.* 
prefix to the keys of the direct response as well...


Is it just an oversight, or did it have a good reason for it?

=nat

(2010/02/01 13:49), nara hideki wrote:

Hello all,

I'm thinking of the good reason why "openid." name space to keys of
Key-Value Form Encoding used for direct responses is dropped.
I think that we MAY use "openid." name space.

I'm very happy if someone give me a good cue to understand the reason.

Thanks in advance.

hdknr
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs
   



--
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

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

Re: Problem with nonces and HTTP GET

[Nat Sakimura]

(2010/01/28 16:21), Allen Tom wrote:

Hi all -

Before I get started -- I agree that in an ideal world, we'd have full 
end to end SSL, old browsers would be banned, and we'd POST data.


However, requiring RPs to support SSL isn't going to help adoption and 
is deal breaker for most applications that want to use OpenID today. 
Encouraging RPs to use SSL is a great idea -- but it should not be 
required.


Although most browsers can support URLs > 2KB, some proxy servers 
choke on URLs > 2KB. This is not fun to debug.

I add one more thing here: Many mobile browsers choke.


In practice, enforcing the nonce only gives the illusion of additional 
security. If there's a MITM, instead of replaying (or pre-playing) the 
assertion, the attacker will just steal the browser cookies instead. 
Assertions should have a limited lifetime -- but this can be enforced 
by checking the timestamp and allowing for a narrow replay window.


POST is technically the ideal solution, but results in a degraded UX. 
The proprietary market leaders have set the bar very high and we need 
to offer an open alternative that is just as good, if not better. We 
really aren't going to get anywhere with a clunky UX.  POST adds 
additional latency, and can cause strange warnings and a blank 
interstitial (the self submitting form).


I really would like to be able to return an assertion using AX with a 
lot of attributes, and Hybrid that can fit within the 2KB limit. This 
is needed just to reach parity with the proprietary stuff.
Artifact Binding :-) Our implementation is returning (for the experiment 
purpose) assertion that is well over 5MB with AX.


=nat


Allen


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



--
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

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

Re: [OIDFSC] AX 1.1 WG Proposal

[Nat Sakimura]

Yes, we definitely need it (for IPR control reason).
I'd volunteer for an admin.

Will it be a google group?
For repository etc., I have setup one at bitbucket.org/openid/ax



=nat

(2010/01/28 18:14), David Recordon wrote:

Let me know if you need a mailing list and who is the admin for it.

On Thu, Jan 21, 2010 at 6:51 PM, Nat Sakimura <mailto:sakim...@gmail.com>> wrote:


Indeed. And, I have started collecting the Contribution Agreement
from the proposers.

Cheers!

=nat


On Fri, Jan 22, 2010 at 7:11 AM, Mike Jones
mailto:michael.jo...@microsoft.com>>
wrote:

Hi all,

In catching up on the specs mail I noticed that the specs
council (myself included) had not made a recommendation about
this proposal.  Under the newly approved IPR policy

<http://openid.net/wordpress-content/uploads/2010/01/OpenID_Process_Document_December_2009_Final_Approved.pdf>
(relevant section quoted below), since the council had not
made a recommendation within 15 days, the working group is
automatically approved.

*4.2  Review.*  The Specifications Council will review each
proposal within 15 days after receipt and promptly provide
notice to sp...@openid.net <mailto:sp...@openid.net> of its
recommendation to either accept or reject it, together with a
brief statement of the rationale for its recommendation
(including any findings or opinions by the Specifications
Council regarding the criteria for rejection in the following
clauses (a)-(d). If a proposal is rejected, it may be modified
and resubmitted.  The reasons for rejection will be limited to:

*(a) *an incomplete Proposal (i.e., failure to comply with §4.1);

*(b) *a determination that the proposal contravenes the OpenID
community’s purpose;

*(c) *a determination that the proposed WG does not have
sufficient support to succeed or to deliver proposed
deliverables within projected completion dates; or

*(d) *a  determination that the proposal is likely to cause
legal liability for the OIDF or others.

If no recommendation was issued within 15 days after receipt,
the Proposal is deemed to be accepted.

Nat, I believe that the next steps for you to take are to
create the working group mailing list and put members on the
list once their signed contribution agreements

<http://openid.net/wordpress-content/uploads/2008/03/paper-contribution-agr-final-clean-20080107.pdf>
for the working group have been received.

   
Best wishes,


--
Mike

-Original Message-
From: openid-specs-boun...@lists.openid.net
<mailto:openid-specs-boun...@lists.openid.net>
[mailto:openid-specs-boun...@lists.openid.net
<mailto:openid-specs-boun...@lists.openid.net>] On Behalf Of
Nat Sakimura
Sent: Monday, December 28, 2009 11:30 PM
To: specs-coun...@openid.net <mailto:specs-coun...@openid.net>
Cc: openid-specs@lists.openid.net
<mailto:openid-specs@lists.openid.net>
Subject: AX 1.1 WG Proposal

Dear Specs Council Representative:

Here is the Proposal for Attribute Exchange 1.1 Working Group
creation.

We have reached the substantial consensus on the scope in
sp...@openid.net <mailto:sp...@openid.net>.

Please review it towards the formation of the WG.

Yours Faithfully,

Nat Sakimura

=

OpenID Attribute Exchange 1.1 Working Group

=

Charter Proposal

In accordance with the OpenID Foundation IPR policies and
procedures

this note proposes the formation of a new working group
chartered to

produce an OpenID specification. As per Section 4.1 of the
Policies,

the proposed charter is below.

I. Name

Attribute Exchange Extension 1.1 Working Group (AX)

II. Statement of Purpose

Produce an updated version of the Attribute Exchange (AX) and
Simple

Registration (SREG) Extensions. The extensions should be

backwards-compatible with AX 1.0.

III. Scope

Update the Attribute Exchange Extension to include support for
the following:

Including parameters in fetch requests.

Including privacy information.

Providing short names for common attributes.

IV. Specifications

OpenID Attribute Exchange 1.1

V. Anticipated audience

All those interested in th

Re: Problem with nonces and HTTP GET

[Nat Sakimura]

(2010/01/28 14:41), Andrew Arnott wrote:

John,

Can you help me understand the risk of a replay if SSL protected the 
message such that you have very high confidence that the only person 
who could be replaying it is the person who should be able to log in 
anyway?
Browser is a default MITM. Browser plug-in type of thing can look at the 
traffic, and send it to the attacker, and the attacker can use is later 
to impersonate the user.


For MITM for HTTPS, refer to something like 
http://www.sans.org/reading_room/whitepapers/threats/ssl_maninthemiddle_attacks_480




IOW, what's the problem with replay if there's no chance of MITM attacks?

On the other hand, I'm not entirely convinced that nonces are all that 
useful, since any MITM could also conceivably /pre/play the message, 
and get in anyway.  Encryption seems to really be the best/only 
mitigation.


Assertion is signed and given that nonce has sufficient level of entropy 
and randomness, it should be pretty hard to preplay, is it not?



--
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 Wed, Jan 27, 2010 at 5:22 PM, John Bradley <mailto:john.brad...@wingaa.com>> wrote:


I think it has been increased.  It would probably be a boon to the
internet if all versions of IE prior to 8 are deprecated.

However I have a hart time seeing websites turning people away due
to old browsers.

It is possible for a IdP to detect the browser and use GET up to
4K + if it is safe.

That won't solve the problem that nonces do what they are supposed
to and prevent token resubmission.

John B.
On 2010-01-27, at 10:12 PM, Henrik Biering wrote:

>
> John Bradley wrote:
>>
>> The other alternative is to ban IE because it is the source of
the 2K limit for GET.
>> Not a problem for FF or other browsers.
> Although I cannot find any official documentation, it seems that
the traditional 2K  limit for IE GET requests has been increased
significantly in IE8
>
> =henrik

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



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



--
Nat Sakimura (n-sakim...@nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

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

Re: Problem with nonces and HTTP GET

[Nat Sakimura]

Andrew,

The way I am writing the Artifact Binding draft is such that the RP always
uses POST to communicate directly with OP.
RP obtains the Artifact by POSTing request to the OP. Note that a different
nonce should result in different artifact.

Then the Artifact is redirected via GET to the OP through the browser.

The OP returns another artifact (which can be the same with the requested
artifact). Ideally, there should be a one-to-one mapping between the request
Artifact and the response Artifact. (One easy way is to make them the same.)
Then the GET has no side effect on that request and thus does not violate
HTTP.

The RP, upon receipt of the response Artifact, will POST it to the OP to
obtain the assertion. If it was the first time, then it will get a positive
assertion. If it was a repeated POST, then a negative assertion will be
returned. Since it is a POST, it should be OK for the request to have side
effects.

Cheers,

=nat

On Thu, Jan 28, 2010 at 8:57 AM, Andrew Arnott wrote:

>
>
> John,
> Remember the argument I'm making is not "how do we get GET to work better"
> but "how do we stop using GET and switch to POST", since that will alleviate
> the nonce reuse problem.   Coming up with craftier ways of using GET is
> moving in the wrong direction IMO.  I'd like to see OpenID move to an
> all-POST protocol, and solve the HTTP-HTTPS boundary problem.
>
> Even with artifact binding moving the nonce outside the browser redirect
> URL, if only one GET is allowed because the artifact is a usable-once-only
> token, then it's not a GET--it's a POST by HTTP definition.
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: Problem with nonces and HTTP GET

[Nat Sakimura]

Title: Re: Problem with nonces and HTTP GET




Actually, we have created artifact binding implementation based on the
draft that I showed you guys at IIW. We now have ones for Java, Python,
PHP, and we are doing Ruby now. Java extended openid4java, and Python
and PHP extended JanRain. The same will be true for Ruby. 

They work nicely, and we are going to be doing experiments with
Japanese mobile telcos in February. 

As to the timing for specing, I am going to be submitting WG proposal
soon. I have the first draft to go with it, and I do not foresee too
much open issues with them, so it should not take too long to bake the
spec, hopefully. It actually is a very small spec, so it might finish
sooner than AX 1.1. 

For those of you who are interested in Artifact Binding, please start
processing your Contribution Agreement, so that we can start the real
work without delay. 

Nat Sakimura (=nat)

(2010/01/28 8:01), Allen Tom wrote:

  
  At least with regards to HuffPo – we ended up
removing attributes from the request to get under the 2KB url limit,
which eliminated the security warning since we can return the response
via GET instead of POST.
  
At least in the near term, I’d like to compact AX so that we can
squeeze in more data – we should be able to do this for AX 1.1. OPs can
also implement this internal artifact mechanism to switch from HTTPS to
HTTP before returning the data. 
  
In the longer term, some form of Artifact Binding would probably be
better, but I guess this would take longer to implement.
  
Allen
  
  
  
On 1/22/10 10:59 AM, "Brian Kissel" <bkis...@janrain.com> wrote:
  
  
  +1 Allen, here’s what I
get on HuffPo, not very compelling and probably a trigger to “Cancel”
to most users.  We need to fix this ASAP!
 

 

Cheers,

Brian
___
 
Brian Kissel <http://www.linkedin.com/pub/0/10/254>

CEO - JanRain, Inc.
bkis...@janrain.com
Mobile: 503.342.2668 | Fax: 503.296.5502
519 SW 3rd Ave. Suite 600  Portland, OR 97204
 
Increase registrations, engage users, and grow your brand
with RPX.  Learn more at www.rpxnow.com
<http://www.rpxnow.com/>

 

From:
openid-specs-boun...@lists.openid.net
[mailto:openid-specs-boun...@lists.openid.net]
On Behalf Of Allen Tom
Sent: Friday, January 22, 2010 10:43 AM
To: Andrew Arnott; John Bradley; Breno de Medeiros; specs
Subject: Re: Problem with nonces and HTTP GET
 
The SSL security warning is a really terrible
UX, and I agree that it doesn’t make sense to warn on POST but not on
GET.

Yahoo is running into the 2KB limit (and the associated SSL warning)
with alarming frequency and it’s really hurting OpenID relative to the
proprietary SSO solutions. 

For a real live example of how the giant AX names are hurting OpenID,
see http://www.huffingtonpost.com
– click on the Login link, then the “Connect with Yahoo” button. This
kicks off the Hybrid OpenID+Oauth+AX flow which requires a POST
response – forcing the user to click through a security warning to
complete the sign in flow. The non-OpenID SSO choices
(Facebook/Twitter/GFC) do not have this issue.

With regards to changing browsers to not display SSL warnings for POST,
or relying on smart OpenID clients – we really need a solution right
now, since the proprietary alternatives are rapidly being adopted.

WRT the nonce – I think it would make more sense for RPs to just check
the timestamp, and allow replay for a “narrow” window, like 10 minutes.
There are many legitimate reasons why a request could be replayed –
intermediate proxy servers might do weird things, the user might hit
reload/back/forward etc.

Allen


On 1/22/10 10:06 AM, "Andrew Arnott" <andrewarn...@gmail.com> wrote:
Ideally we could use POST, but avoid the browser warning that
information is crossing the SSL world into the non-SSL world.  This
might be arguable anyway since sending information can be done with GET
or POST, so why warn for POST and not for GET?  If we can get browsers
to not warn for POST we're gold.

Alternatively, and perhaps more likely, if we're moving in the
direction of smart client browser (plugins), and these have been shown
to benefit from extensions to the OpenID spec, perhaps we can leverage
these to always use POST without displaying the warning to the user
somehow.  
--
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 Fri, Jan 22, 2010 at 9:14 AM, John Bradley <john.brad...@wingaa.com>
wrote:
The big problem with POST is RP's that use non-ssl endpoints. 

One possibility is that the IdP could look at the return_to and
discover if it is safe to use POST.

In SAML SSO POST is the most common way to return the token.   

The other option is artifact binding.  That way the nonce is not in the
GET,  though you pr

Re: AX 1.1 WG Proposal

[Nat Sakimura]

Indeed. And, I have started collecting the Contribution Agreement from the
proposers.

Cheers!

=nat

On Fri, Jan 22, 2010 at 7:11 AM, Mike Jones wrote:

>  Hi all,
>
>
>
> In catching up on the specs mail I noticed that the specs council (myself
> included) had not made a recommendation about this proposal.  Under the
> newly approved IPR 
> policy<http://openid.net/wordpress-content/uploads/2010/01/OpenID_Process_Document_December_2009_Final_Approved.pdf>(relevant
>  section quoted below), since the council had not made a
> recommendation within 15 days, the working group is automatically approved.
>
>
>
> *4.2  Review.*  The Specifications Council will review each proposal
> within 15 days after receipt and promptly provide notice to
> sp...@openid.net of its recommendation to either accept or reject it,
> together with a brief statement of the rationale for its recommendation
> (including any findings or opinions by the Specifications Council regarding
> the criteria for rejection in the following clauses (a)-(d). If a proposal
> is rejected, it may be modified and resubmitted.  The reasons for rejection
> will be limited to:
>
> *(a)*an incomplete Proposal (i.e., failure to comply with §4.1);
>
> *(b)*a determination that the proposal contravenes the OpenID
> community’s purpose;
>
> *(c) *a determination that the proposed WG does not have sufficient
> support to succeed or to deliver proposed deliverables within projected
> completion dates; or
>
> *(d)*a  determination that the proposal is likely to cause legal
> liability for the OIDF or others.
>
> If no recommendation was issued within 15 days after receipt, the Proposal
> is deemed to be accepted.
>
>
>
> Nat, I believe that the next steps for you to take are to create the
> working group mailing list and put members on the list once their signed 
> contribution
> agreements<http://openid.net/wordpress-content/uploads/2008/03/paper-contribution-agr-final-clean-20080107.pdf>for
>  the working group have been received.
>
>
>
> Best wishes,
>
>         -- Mike
>
>
>
> -Original Message-
> From: openid-specs-boun...@lists.openid.net [mailto:
> openid-specs-boun...@lists.openid.net] On Behalf Of Nat Sakimura
> Sent: Monday, December 28, 2009 11:30 PM
> To: specs-coun...@openid.net
> Cc: openid-specs@lists.openid.net
> Subject: AX 1.1 WG Proposal
>
>
>
> Dear Specs Council Representative:
>
>
>
> Here is the Proposal for Attribute Exchange 1.1 Working Group creation.
>
> We have reached the substantial consensus on the scope in sp...@openid.net
> .
>
> Please review it towards the formation of the WG.
>
>
>
> Yours Faithfully,
>
>
>
> Nat Sakimura
>
>
>
> =
>
> OpenID Attribute Exchange 1.1 Working Group
>
> =
>
>
>
> Charter Proposal
>
>
>
> In accordance with the OpenID Foundation IPR policies and procedures
>
> this note proposes the formation of a new working group chartered to
>
> produce an OpenID specification. As per Section 4.1 of the Policies,
>
> the proposed charter is below.
>
>
>
> I. Name
>
>
>
> Attribute Exchange Extension 1.1 Working Group (AX)
>
>
>
> II. Statement of Purpose
>
>
>
> Produce an updated version of the Attribute Exchange (AX) and Simple
>
> Registration (SREG) Extensions. The extensions should be
>
> backwards-compatible with AX 1.0.
>
>
>
> III. Scope
>
>
>
> Update the Attribute Exchange Extension to include support for the
> following:
>
>
>
> Including parameters in fetch requests.
>
> Including privacy information.
>
> Providing short names for common attributes.
>
>
>
>
>
> IV. Specifications
>
>
>
> OpenID Attribute Exchange 1.1
>
>
>
> 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 1.1 final drafts are delivered.
>
>
>
> Background Information
>
>
>
> IX. Related Work
>
>
>
> Attribute Exchange (1.0), and Simpl

AX 1.1 WG Proposal

[Nat Sakimura]

Dear Specs Council Representative:

Here is the Proposal for Attribute Exchange 1.1 Working Group creation.
We have reached the substantial consensus on the scope in sp...@openid.net.
Please review it towards the formation of the WG.

Yours Faithfully,

Nat Sakimura

=
OpenID Attribute Exchange 1.1 Working Group
=

Charter Proposal

In accordance with the OpenID Foundation IPR policies and procedures
this note proposes the formation of a new working group chartered to
produce an OpenID specification. As per Section 4.1 of the Policies,
the proposed charter is below.

I. Name

Attribute Exchange Extension 1.1 Working Group (AX)

II. Statement of Purpose

Produce an updated version of the Attribute Exchange (AX) and Simple
Registration (SREG) Extensions. The extensions should be
backwards-compatible with AX 1.0.

III. Scope

Update the Attribute Exchange Extension to include support for the following:

Including parameters in fetch requests.
Including privacy information.
Providing short names for common attributes.


IV. Specifications

OpenID Attribute Exchange 1.1

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 1.1 final drafts are delivered.

Background Information

IX. Related Work

Attribute Exchange (1.0), and Simple Registration (1.0 and 1.1 Draft).

X. Initial Membership

Allen Tom, 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)
John Bradley, ve7...@ve7jtb.com
Will Norris, w...@willnorris.com

XI. Expected contribution

http://lists.openid.net/pipermail/openid-specs/attachments/20091117/c5754ef7/attachment-0001.html

=


-- Forwarded message --
From: Breno de Medeiros 
Date: Fri, Nov 20, 2009 at 3:07 AM
Subject: Re: AX and Artifact Binding Charter Proposal
To: John Bradley 
Cc: Nat Sakimura , openid-specs@lists.openid.net


+1

On Thu, Nov 19, 2009 at 9:46 AM, John Bradley  wrote:
> I can live with Nat's latest edit based on Dick's input.
>
> Let's call the scope done.
>
> John B.
> On 2009-11-19, at 2:39 PM, Breno de Medeiros wrote:
>
>> Agree, let's define the scope, create the WG and then we can have
>> discussions there.
>>
>> On Thu, Nov 19, 2009 at 7:33 AM, Nat Sakimura  wrote:
>>> Will,
>>> You are right, but that will be incompatible with AX 1.0, and the
>>> prerequisite of the scope is that it should be backward compatible. I feel
>>> that keeping aliases is a small compromise for keeping the compatibility and
>>> flexibility.
>>> =nat
>>>
>>> On Thu, Nov 19, 2009 at 12:37 PM, Will Norris  wrote:
>>>>
>>>> On Nov 18, 2009, at 7:27 PM, Nat Sakimura wrote:
>>>>
>>>>> (2009/11/18 15:04), Will Norris wrote:
>>>>>> On Nov 16, 2009, at 6:42 PM, Nat Sakimura wrote:
>>>>>>
>>>>>>
>>>>>>> (2009/11/17 10:58), Will Norris wrote:
>>>>>>>
>>>>>>>> On Nov 16, 2009, at 3:49 PM, Nat Sakimura wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Right. AX 1.1 is to be expedient so that it will remove the current
>>>>>>>>> acute
>>>>>>>>> pain.
>>>>>>>>> It should be minimalistic as to the spec change and to the
>>>>>>>>> implementation
>>>>>>>>> change.
>>>>>>>>>
>>>>>>>>> AX 2.0 will be more generic fix, and that is the place we should
>>>>>>>>> consider
>>>>>>>>> whole bunch of issues.
>>>>>>>>>
>>>>>>>>> I agree that there should be discovery way of it in XRD/s for many
>>>>>>>>> use
>>>>>>>>> cases,
>>>>>>>>> but it seems to me to be in the territory of AX2.0.
>>>>>>>>>
>>>>>>>>> Attached please find the first cut of AX1.1 Draft01.
>>>>>>>>>
>>>>>>>>>
&

Re: Yahoo available AX attrs - backchannel/endpoint URLs

[Nat Sakimura]

(I thought I posted a reply but since it does not appear in the archive
etc...)

+1 to Breno's point.

With Artifact Binding, you will not have to worry about the URL length
limit,
and we get the benefit for other extensions as well.

We have working code for Artifact Binding for Python, Java, and now making
PHP
version.

For making a custom grouping of the attribute, we can create a file that
contains the list and use the file's URL as the group's type URL. Current
draft of Contract Exchange has such facility. It stores the ax request in
one of the node of the Contract Document (which has other items like
signature etc. as well.)

=nat

On Wed, Dec 9, 2009 at 4:08 AM, Breno de Medeiros  wrote:

> On Tue, Dec 8, 2009 at 11:01 AM, John Panzer  wrote:
> > For "one-time" URLs, you'd probably want to allow for retries for a short
> > period (or just allow it to be accessed for say 5m) which would have
> > approximately the same level of protection.
> > You could also imagine long-lived capabilities along the lines of OAuth
> > tokens that allow RPs to repeatedly refresh the data as needed.  (Better
> of
> > course if they can subscribe to changes, but that's an implementation
> detail
> > and definitely a separate spec.)
> > Given that AX already supports requesting URL-valued data (e.g., profile
> > photos) I think this just comes down to defining a fairly complicated
> data
> > type for AX and passing a URL around.
>
> A more lightweight alternative is to adopt an 'artifact' mode where
> most of the OpenID assertion (request and response) can be passed in
> the backchannel. That is a bit more difficult to implement but easier
> to spec (because the existing URLs can be used) and more general
> (compacts all extensions, not only AX).
>
> > --
> > John Panzer / Google
> > jpan...@google.com / abstractioneer.org / @jpanzer
> >
> >
> >
> > On Tue, Dec 8, 2009 at 10:57 AM, Peter Watkins  wrote:
> >>
> >> On Tue, Dec 08, 2009 at 10:32:12AM -0800, John Panzer wrote:
> >>
> >> > provide to RPs.  If you send an endpoint URL to the RP instead of the
> >> > information itself, the RP can then retrieve it via a backchannel (and
> >> > cache
> >> > it).  If you have private data, use a capability URL with a token that
> >> > allows read-only access.
> >>
> >> Exactly. OpenID requests and responses are very chatty, and backchannel
> >> URLs could be an easy way to get around the 2k GET limit (the cost of
> >> course being additional time needed to make the additional HTTP
> requests).
> >>
> >> I don't see any reason for backchannel URLs to be requested multiple
> >> times,
> >> so in addition to a request or response using strongly random nonces in
> >> the backchannel URLs, the backchannel URLs should be very short-lived,
> >> probably each side "SHOULD" allow a URL to be requested only once, and
> >> throw a 403/404 for subsequent requests.
> >>
> >> Is there any draft of AX using backchannel URLs?
> >>
> >> -Peter
> >
> >
> > _______
> > specs mailing list
> > sp...@lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-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
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: AX1.1 draft 02

[Nat Sakimura]

On Thu, Dec 10, 2009 at 12:06 AM, Santosh Rajan  wrote:

> +1, Nat, Another shameless bump from me, of this post, for the voting.
>
> I don't agree with the /XRDS/xrd/Service/Type, but we will leave that for
> later.
>

Yes, I am just throwing in the stuff for discussion in the forthcoming WG.



>
>
>
> On Wed, Dec 9, 2009 at 8:30 PM, Nat Sakimura  wrote:
>
>> While we are waiting for the IPR process change (if you have not voted,
>> please vote NOW! [1])
>> I took a liberty of making a github repository for the time being.
>>
>> http://github.com/sakimura/attribute_exchange_1.1
>>
>> I have commited draft 02 there.
>>
>> Only one change apart from bumping up the revision:
>>
>> - Added a paragraph in discovery section to state that the provider
>> should
>>   advertise the attribute url they supports in /XRDS/xrd/Service/Type.
>>
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>>
>> ___
>> specs mailing list
>> sp...@lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>
>>
>
>
> --
> http://hi.im/santosh
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

AX1.1 draft 02

[Nat Sakimura]

While we are waiting for the IPR process change (if you have not voted,
please vote NOW! [1])
I took a liberty of making a github repository for the time being.

http://github.com/sakimura/attribute_exchange_1.1

I have commited draft 02 there.

Only one change apart from bumping up the revision:

- Added a paragraph in discovery section to state that the provider should
  advertise the attribute url they supports in /XRDS/xrd/Service/Type.

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Attribute Type URLs (was Re: specs Digest, Vol 40, Issue 11)

[Nat Sakimura]

David,

PoCo seems to be only for contacts. Attributes are not just contacts but 
bunch of other things as well.


Even within the "contacts", it is missing out things like phonetics 
(e.g., furigana), sort order, etc.

It does not seem to have had a lot of international exposure.

Also, by just briefly scanning, I can point out that current proposal 
does not have email classes like MMS/SMS/mobile phone etc. which are 
very commonly asked attribute in Japan. Many sites refuses to provide 
service without it. I bet there are other things from European point of 
view etc.


IMHO, we should define those attribute URL in an Open Forum with a clear 
process and a lot of international participation.


=nat

(2009/12/09 11:56), David Recordon wrote:

Hey Nat,
I guess I'm wondering what is missing from the PoCo schema that we've
seen the need for within the OpenID ecosystem?  It seems really rich
already.

I don't think that IPR is an issue around a schema, but would also be
happy to have Facebook do an OWF agreement if it was deemed necessary.
  That said, we should focus on making sure this solves the problem of
profile data adoption first! :)

--David

On Tue, Dec 8, 2009 at 5:21 PM, Nat Sakimura  wrote:
   

Looks nice.
What is the process for adding more?
I would like to add more like phonetic field for names and addresses.
(In Japanese, we call them "furigana". Without them, we do not know
  how to read in many cases nor the sort order.)
Also, I feel that portablecontacts.net is a bit long...
Is portablecontacts only for the contact data or trying to be a general
schema repository like axschema? Is there any consensus in which direction
we should head to?
What is the IPR implication?
=nat
On Wed, Dec 9, 2009 at 8:32 AM, Chris Messina
wrote:
 

Done.
https://portablecontacts.pbworks.com/schema

On Tue, Dec 8, 2009 at 1:45 PM, Joseph Smarr  wrote:
   

Looks great to me, the only thing missing is sub-fields of complex fields
like name, address, organization, and account. I would suggest using another
level of slashes, e.g.
http://portablecontacts.net/ns/1.0/address/streetAddress and
http://portablecontacts.net/ns/1.0/name/familyName and so on.

Chris-can you take a stab at adding those missing sub-fields? Then I
think we'd be good to go.

Thanks, js

From: Chris Messina [mailto:chris.mess...@gmail.com]
Sent: Sunday, December 06, 2009 6:40 PM
To: David Recordon
Cc: SitG Admin; openid-specs@lists.openid.net; Joseph Smarr
Subject: Re: specs Digest, Vol 40, Issue 11

I've taken a crack at URLizing these attributes for use in Attribute
Exchange:
https://portablecontacts.pbworks.com/schema
If there are comments or feedback for improving this, let me know. I'm an
XML noob.
Chris

On Sun, Dec 6, 2009 at 5:05 PM, David Recordon
wrote:
 

It's missing out on the idea of having a schema which can cross
contexts.  Right now each schema – with the exception of AXSchema.org
– has no concept of namespaces and stands alone.  We've always wanted
a schema which uses URLs to identify each element, but there haven't
been any.  Maybe Portable Contacts wants to take this on since it is
also used by OpenSocial?

--David

On Sun, Dec 6, 2009 at 5:01 PM, Chris Messina
wrote:
   

I did this in June:

http://spreadsheets.google.com/pub?key=pSGbbhtwI4kN_nJ1GXeQ7Qg&output=html
I just wish someone would actually use it!
Chris

On Sun, Dec 6, 2009 at 4:02 PM, SitG Admin

wrote:
 

I'm specifically pointing out that AXSchema reinvents vcard and a
host of
other profile formats, which adds yet another burden for developers
to map
other schema, like Portable Contacts, to the AXSchema.
 

Could these other profile formats be mapped, on an alias, to a set of
AXScheme that collectively mirror each format? As in, "vcard" alias
maps to
a set of AXSchema that actually just mirror 'vcard' format.

-Shade
   



--
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] shareable[X] ask first   [ ] private

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


 



--
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] shareable[X] ask first   [ ] private
 



--
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://di

Re: specs Digest, Vol 40, Issue 11

[Nat Sakimura]

Looks nice.

What is the process for adding more?
I would like to add more like phonetic field for names and addresses.
(In Japanese, we call them "furigana". Without them, we do not know
 how to read in many cases nor the sort order.)

Also, I feel that portablecontacts.net is a bit long...

Is portablecontacts only for the contact data or trying to be a general
schema repository like axschema? Is there any consensus in which direction
we should head to?

What is the IPR implication?

=nat

On Wed, Dec 9, 2009 at 8:32 AM, Chris Messina wrote:

> Done.
>
> https://portablecontacts.pbworks.com/schema
>
> On Tue, Dec 8, 2009 at 1:45 PM, Joseph Smarr  wrote:
>
>>  Looks great to me, the only thing missing is sub-fields of complex
>> fields like name, address, organization, and account. I would suggest using
>> another level of slashes, e.g.
>> http://portablecontacts.net/ns/1.0/address/streetAddress and
>> http://portablecontacts.net/ns/1.0/name/familyName and so on.
>>
>> Chris-can you take a stab at adding those missing sub-fields? Then I think
>> we'd be good to go.
>>
>> Thanks, js
>>
>>  --
>> *From:* Chris Messina [mailto:chris.mess...@gmail.com]
>> *Sent:* Sunday, December 06, 2009 6:40 PM
>> *To:* David Recordon
>> *Cc:* SitG Admin; openid-specs@lists.openid.net; Joseph Smarr
>> *Subject:* Re: specs Digest, Vol 40, Issue 11
>>
>> I've taken a crack at URLizing these attributes for use in Attribute
>> Exchange:
>>
>> https://portablecontacts.pbworks.com/schema
>>
>> If there are comments or feedback for improving this, let me know. I'm an
>> XML noob.
>>
>> Chris
>>
>> On Sun, Dec 6, 2009 at 5:05 PM, David Recordon wrote:
>>
>>> It's missing out on the idea of having a schema which can cross
>>> contexts.  Right now each schema – with the exception of AXSchema.org
>>> – has no concept of namespaces and stands alone.  We've always wanted
>>> a schema which uses URLs to identify each element, but there haven't
>>> been any.  Maybe Portable Contacts wants to take this on since it is
>>> also used by OpenSocial?
>>>
>>> --David
>>>
>>> On Sun, Dec 6, 2009 at 5:01 PM, Chris Messina 
>>> wrote:
>>> > I did this in June:
>>> >
>>> http://spreadsheets.google.com/pub?key=pSGbbhtwI4kN_nJ1GXeQ7Qg&output=html
>>> > I just wish someone would actually use it!
>>> > Chris
>>> >
>>> > On Sun, Dec 6, 2009 at 4:02 PM, SitG Admin <
>>> sysad...@shadowsinthegarden.com>
>>> > wrote:
>>> >>>
>>> >>> I'm specifically pointing out that AXSchema reinvents vcard and a
>>> host of
>>> >>> other profile formats, which adds yet another burden for developers
>>> to map
>>> >>> other schema, like Portable Contacts, to the AXSchema.
>>> >>
>>> >> Could these other profile formats be mapped, on an alias, to a set of
>>> >> AXScheme that collectively mirror each format? As in, "vcard" alias
>>> maps to
>>> >> a set of AXSchema that actually just mirror 'vcard' format.
>>> >>
>>> >> -Shade
>>> >
>>> >
>>> >
>>> > --
>>> > Chris Messina
>>> > Open Web Advocate
>>> >
>>> > Personal: http://factoryjoe.com
>>> > Follow me on Twitter: http://twitter.com/chrismessina
>>> >
>>> > Citizen Agency: http://citizenagency.com
>>> > Diso Project: http://diso-project.org
>>> > OpenID Foundation: http://openid.net
>>> >
>>> > This email is:   [ ] shareable[X] ask first   [ ] private
>>> >
>>>  > ___
>>> > specs mailing list
>>> > sp...@lists.openid.net
>>> > http://lists.openid.net/mailman/listinfo/openid-specs
>>> >
>>> >
>>>
>>
>>
>>
>> --
>> Chris Messina
>> Open Web Advocate
>>
>> Personal: http://factoryjoe.com
>> Follow me on Twitter: http://twitter.com/chrismessina
>>
>> Citizen Agency: http://citizenagency.com
>> Diso Project: http://diso-project.org
>> OpenID Foundation: http://openid.net
>>
>> This email is:   [ ] shareable[X] ask first   [ ] private
>>
>
>
>
> --
> Chris Messina
> Open Web Advocate
>
> Personal: http://factoryjoe.com
> Follow me on Twitter: http://twitter.com/chrismessina
>
> Citizen Agency: http://citizenagency.com
> Diso Project: http://diso-project.org
> OpenID Foundation: http://openid.net
>
> This email is:   [ ] shareable[X] ask first   [ ] private
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: specs Digest, Vol 40, Issue 11

[Nat Sakimura]

IMHO, all the data types in your table should be supported, and then grouped
into "classes".

Portable contact is very useful, but so is vCard, as you can use it to
populate many address books. (Besides, vCard covers everything in Portable
contact.)
It is not much of fragmentations nor too much work on the OP part.

Having said that, I am not particularly pushing for vCard. It was a merely
an example of the notion of the "class".


On Tue, Dec 8, 2009 at 12:42 AM, Chris Messina wrote:

> I think that would create mire fragmentation at thus point.
>
> I think PortableContacts is the right collection of attributes for AX and
> OpenID and should largely be adopted as the standard for OpenID. Facebook
> Connect is much easier to work with because it reduces complexity and the
> number of options for doing things -- like the number of formats for
> accessing user data.
>
> If sites that want to adopt OpenID have to learn some custom profile data
> schema AS WELL AS PortableContacs -- they're likely to skip it and go
> straight to FB Connect.
>
> I've proposed a schema for using PoCo with AX; why don't we move to improve
> it and make it the standard for OpenID going forward?
>
> Chris
>
> Sent from my iPhone 2G
>
>
> On Dec 7, 2009, at 6:53, Nat  wrote:
>
>  Shade,
>>
>> That's exactly what I was proposing: the class for AX.
>>
>> For example, vCard will be one class in axschema. The same for openSocial
>> person etc.
>>
>> e.g.
>>
>> http://axschema.org/vCard will specify all the sub-items of a vCard.
>>
>> What do you think?
>>
>> =...@tokyo via iPhone
>>
>> On 2009/12/07, at 10:05, David Recordon  wrote:
>>
>>  It's missing out on the idea of having a schema which can cross
>>> contexts.  Right now each schema – with the exception of AXSchema.org
>>> – has no concept of namespaces and stands alone.  We've always wanted
>>> a schema which uses URLs to identify each element, but there haven't
>>> been any.  Maybe Portable Contacts wants to take this on since it is
>>> also used by OpenSocial?
>>>
>>> --David
>>>
>>> On Sun, Dec 6, 2009 at 5:01 PM, Chris Messina 
>>> wrote:
>>>
>>>> I did this in June:
>>>>
>>>> http://spreadsheets.google.com/pub?key=pSGbbhtwI4kN_nJ1GXeQ7Qg&output=html
>>>> I just wish someone would actually use it!
>>>> Chris
>>>>
>>>> On Sun, Dec 6, 2009 at 4:02 PM, SitG Admin <
>>>> sysad...@shadowsinthegarden.com>
>>>> wrote:
>>>>
>>>>>
>>>>>> I'm specifically pointing out that AXSchema reinvents vcard and a host
>>>>>> of
>>>>>> other profile formats, which adds yet another burden for developers to
>>>>>> map
>>>>>> other schema, like Portable Contacts, to the AXSchema.
>>>>>>
>>>>>
>>>>> Could these other profile formats be mapped, on an alias, to a set of
>>>>> AXScheme that collectively mirror each format? As in, "vcard" alias
>>>>> maps to
>>>>> a set of AXSchema that actually just mirror 'vcard' format.
>>>>>
>>>>> -Shade
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Chris Messina
>>>> Open Web Advocate
>>>>
>>>> Personal: http://factoryjoe.com
>>>> Follow me on Twitter: http://twitter.com/chrismessina
>>>>
>>>> Citizen Agency: http://citizenagency.com
>>>> Diso Project: http://diso-project.org
>>>> OpenID Foundation: http://openid.net
>>>>
>>>> This email is:   [ ] shareable[X] ask first   [ ] private
>>>>
>>>> ___
>>>> specs mailing list
>>>> sp...@lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>
>>>>
>>>>  ___
>>> specs mailing list
>>> sp...@lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: specs Digest, Vol 40, Issue 11

[Nat Sakimura]

This is very useful!

On Mon, Dec 7, 2009 at 10:01 AM, Chris Messina wrote:

> I did this in June:
>
> http://spreadsheets.google.com/pub?key=pSGbbhtwI4kN_nJ1GXeQ7Qg&output=html
>
> I just wish someone would actually use it!
>
> Chris
>
>
> On Sun, Dec 6, 2009 at 4:02 PM, SitG Admin <
> sysad...@shadowsinthegarden.com> wrote:
>
>> I'm specifically pointing out that AXSchema reinvents vcard and a host of
>>> other profile formats, which adds yet another burden for developers to map
>>> other schema, like Portable Contacts, to the AXSchema.
>>>
>>
>> Could these other profile formats be mapped, on an alias, to a set of
>> AXScheme that collectively mirror each format? As in, "vcard" alias maps to
>> a set of AXSchema that actually just mirror 'vcard' format.
>>
>> -Shade
>>
>
>
>
> --
> Chris Messina
> Open Web Advocate
>
> Personal: http://factoryjoe.com
> Follow me on Twitter: http://twitter.com/chrismessina
>
> Citizen Agency: http://citizenagency.com
> Diso Project: http://diso-project.org
> OpenID Foundation: http://openid.net
>
> This email is:   [ ] shareable[X] ask first   [ ] private
>
> ___
> specs mailing list
> sp...@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Artifact Binding Charter OK?

[Nat Sakimura]

Hi

The other thread almost got entirely on AX, but in the first post, there was
a link to Artifact Binding as well.
Does the artifact binding charter sounds ok to you?

http://wiki.openid.net/Artifact_Binding

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
___
specs mailing list
sp...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs

Re: AX and Artifact Binding Charter Proposal

[Nat Sakimura]

Will,

You are right, but that will be incompatible with AX 1.0, and the
prerequisite of the scope is that it should be backward compatible. I feel
that keeping aliases is a small compromise for keeping the compatibility and
flexibility.

=nat

On Thu, Nov 19, 2009 at 12:37 PM, Will Norris  wrote:

>
> On Nov 18, 2009, at 7:27 PM, Nat Sakimura wrote:
>
> > (2009/11/18 15:04), Will Norris wrote:
> >> On Nov 16, 2009, at 6:42 PM, Nat Sakimura wrote:
> >>
> >>
> >>> (2009/11/17 10:58), Will Norris wrote:
> >>>
> >>>> On Nov 16, 2009, at 3:49 PM, Nat Sakimura wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Right. AX 1.1 is to be expedient so that it will remove the current
> acute
> >>>>> pain.
> >>>>> It should be minimalistic as to the spec change and to the
> implementation
> >>>>> change.
> >>>>>
> >>>>> AX 2.0 will be more generic fix, and that is the place we should
> consider
> >>>>> whole bunch of issues.
> >>>>>
> >>>>> I agree that there should be discovery way of it in XRD/s for many
> use
> >>>>> cases,
> >>>>> but it seems to me to be in the territory of AX2.0.
> >>>>>
> >>>>> Attached please find the first cut of AX1.1 Draft01.
> >>>>>
> >>>>>
> >>>> It looks like you have policy URL defined as an actual AX attribute?
>  How would that work if the RP is sending the URL to the OP.  Doesn't it
> need to be a standalone parameter like update_url is?
> >>>>
> >>>>
> >>> In this 1.1 draft, I have added the capability for the fetch request to
> include "value"/"parameter".
> >>> Thus, you can do something like:
> >>>
> >>> openid.ns.ax=http://openid.net/srv/ax/1.1
> >>> openid.ax.mode=fetch_request
> >>> openid.ax.type.policy_url=http://axschema.org/policy_url
> >>> openid.ax.value.policy_url=http://examplerp.com/data_usage_policy.html
> >>>
> >> ahh, I missed that.  This actually brings up a bigger concern regarding
> what features go into 1.1 versus 2.0.  During IIW, we talked about needing a
> more robust message format, (even serialized XML or JSON was thrown about).
>  I've heard all kinds of ideas for attached metadata to attributes in an AX
> request...
> >>
> >>  - give me a verified email address
> >>  - give me an email address that was verified using method X
> >>  - tell me if the email address "b...@example.com" belongs to this user
> >>  - give me a payment token authorized for up to $50
> >>
> >> and I'm sure folks have many, many more.  In order to support these
> kinds of scenarios, we will almost certainly need something richer than the
> extended request format currently included in the 1.1 draft.  I'm a little
> concerned about changing the message format for 1.1, and then turning around
> and changing it again for 2.0.  (If others are okay with this prospect, and
> it's just something I need to get over, that's fine)
> >>
> > I understand this concern, but on the other hand, I have got the feeling
> that it will not change too much either.
> > I have got the feeling that it ends up as
> >
> > ax.type.=http://openid.net/spec/ax/2.0/json
> > ax.type.value.=[json file]
> >
> > which is the same as we have now. Only the difference is that we are not
> any more using any other ,
> > and we will not need .count.
> >
> > Of course, we have to agree on how to express attributes in json format,
> agree on signature, etc. and these are the main things that we should be
> dealing with in AX 2.0. Then, the finer semantics / data format / etc.needs
> to be addressed in other WGs specifically for that purpose. CX WG is one
> example of such thing.
> >
> > Needless to say, if you wanted to use SAML assertion in it, you could do
> something like
> >
> > ax.type.=http://openid.net/spec/ax/2.0/saml/2.0
> > ax.type.value.=[saml assertion]
> >
> > etc. as well.
>
> If you're going to do that, then why even keep the aliases around?  Why not
> just have
>
> ns.ax = http://openid.net/specs/ax/2.0
> ax = [json/xml file]
>
> That would be perfectly valid and avoid the overhead.  Now I'm not actually
> suggesting we do this, because I don't think we have a clear understanding
> of the requirements for AX 2.0.  But my point is, we may end u