[Openid-specs-ab] Errata actions list

Tue Apr 14 19:18:34 UTC 2015

My suggestions:

I think it would help to clarify this statement in section 5.3: "The
UserInfo Endpoint MUST accept Access Tokens as OAuth 2.0 Bearer Token Usage
[RFC6750]." such that only the header method is required (mirroring
RFC6750).

Also in 5.3, the UserInfo POST should be a MAY, not a MUST, as POST is only
relevant for OPs that support form-body bearer token usage (which is itself
optional as per RFC6750).

In Section 3.1.2.1. for the "max_age" parameter, perhaps we can add some
text like "The exact method for re-authenticating the End User is out of
scope for this specification"

On Tue, Apr 14, 2015 at 12:03 PM, Mike Jones <Michael.Jones at microsoft.com>
wrote:

>  The list that I’d captured in my OpenID to-do list to date is as
> follows.  If others know of errata actions we will need to take that I’ve
> not captured, please add them to this thread.
>
>
>
> ·         Update examples using Pragma: no-cache to also include
> Cache-Control: no-cache, no-store and add language "Because the
> Authorization Response is intended to be used only once, the Authorization
> Server MUST instruct the User Agent (and any intermediaries) not to store
> or reuse the content of the response." as was done in the Form Post
> Response Mode draft.
>
> ·         James Manger's note about self-issued typos, use of http, etc.
>
> ·         When errata time next comes around, we should think about
> whether to relax the requirement to include a nonce in the request for the
> code+token flow.
>
> ·         I believe that the working group is waiting to apply errata
> changes until the IETF specs in this cluster
> http://www.rfc-editor.org/cluster_info.php?cid=C241 and
> draft-ietf-appsawg-acct-uri are RFCs.  Also, once Google has corrected the
> issue described at
> http://openid.net/specs/openid-connect-core-1_0.html#GoogleIss (which I
> expect has been done in preparation for your certification submissions), we
> can remove this clause through the errata process.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* William Denniss [mailto:wdenniss at google.com]
> *Sent:* Tuesday, April 14, 2015 11:41 AM
> *To:* Mike Jones
> *Cc:* openid-specs-ab at lists.openid.net; Eve Maler
> *Subject:* Re: [Openid-specs-ab] Minor test change to match the spec
>
>
>
> Sounds good. Should we start listing the planned errata on a wiki or
> something, so we don't miss any when the time comes?
>
>
>
> On Tue, Apr 14, 2015 at 11:35 AM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
> I believe that the working group is waiting to apply errata changes until the IETF specs in this cluster http://www.rfc-editor.org/cluster_info.php?cid=C241 and draft-ietf-appsawg-acct-uri are RFCs.  Also, once Google has corrected the issue described at http://openid.net/specs/openid-connect-core-1_0.html#GoogleIss (which I expect has been done in preparation for your certification submissions), we can remove this clause through the errata process.
>
>
>
>                                                                                  -- Mike
>
>
>
> *From:* William Denniss [mailto:wdenniss at google.com]
> *Sent:* Tuesday, April 14, 2015 9:42 AM
> *To:* Mike Jones
> *Cc:* openid-specs-ab at lists.openid.net; Eve Maler
> *Subject:* Re: [Openid-specs-ab] Minor test change to match the spec
>
>
>
> Acknowledged.
>
>
>
> Regarding the next errata, when should we start that process? It seems
> like a good opportunity now, with the certification process still fresh in
> everyone's minds.
>
>
>
>
>
> On Mon, Apr 13, 2015 at 11:04 AM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
>  Garyl Erickson of ForgeRock identified a place where the tests didn’t
> match the spec and Roland just adjusted the tests as a result.  I wanted to
> document this change and the reason for it for the working group.
>
>
>
> OP-nonce-NoReq-code is about supporting requests without a nonce.  The
> nonce is only needed when the ID Token is returned as a fragment.  The
> code+token flow doesn't return the nonce as a fragment.  Therefore, it
> should be legal to make a request with no nonce for code+token.  So the
> test tool had included the test OP-nonce-NoReq-code for both the code and
> code+token response types.
>
>
>
> But the spec says that a nonce is required for Hybrid flows:
> http://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken
> 3.3.2.11 ID Token "Use of the nonce Claim is REQUIRED for this flow."
> Therefore Roland just removed the OP-nonce-NoReq-code test from code+token,
> because it's testing for behavior that violates the spec.  In this case
> while common sense may indicate that you don't have to send a nonce for
> code+token, the spec says that you do.
>
>
>
> In a related test, the OP-nonce-NoReq-noncode is about testing that
> implementations reject requests without a nonce.  Roland and I **did not**
> add this test for the code+token flow because doing so would break existing
> implementations that have already passed certification with this
> functionality, which matches common sense, but not the spec. ;-)  We *
> *did** add this test for the code+id_token and code+id_token+token flows
> because the nonce really is required for security reasons in these cases.
> That being said, per the rules of the test freeze, we will honor any Hybrid
> certifications that have already occurred without these tests having been
> presented by the test tool.
>
>
>
> When errata time next comes around, we should think about whether to relax
> the requirement to include a nonce in the request for the code+token flow.
> But for now, I think it’s right for our certification tests to allow either
> the logical or the specified behavior in this one case.
>
>
>
>                                                             Cheers,
>
>                                                             -- Mike
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150414/12005081/attachment.html>