[Openid-specs-ab] Errata actions list

Wed Apr 15 12:59:26 UTC 2015

There are a couple items in issue tracking too - #968
<https://bitbucket.org/openid/connect/issue/968> & #966
<https://bitbucket.org/openid/connect/issue/966>.

We might consider using issue tracking to track all the pending/potential
errata.

On Tue, Apr 14, 2015 at 1:18 PM, William Denniss <wdenniss at google.com>
wrote:

> 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
>>
>>
>>
>>
>>
>
>
> _______________________________________________
> 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/20150415/138eeee6/attachment.html>