[Openid-specs-ab] FW: HEART Implementer's Drafts Approved

Thomas Broyer t.broyer at gmail.com
Mon Feb 22 10:45:07 UTC 2016


Reading this, I can't help but think back about a question I asked here
that (AFAICT) never had an answer, but has now contradictory spec texts
that reinforce the confusion.

OpenID Connect Session Management 1.0 – draft 26 says:
> An ID Token typically comes with an expiration date. The RP MAY rely on
it to expire the RP session.
> However, it is entirely possible that the End-User might have logged out
of the OP before the expiration
> date. Therefore, it is highly desirable to be able to find out the login
status of the End-User at the OP.
— Source:
https://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification

Health Relationship Trust Profile for OpenID Connect 1.0 says:
> The ID Token MUST expire and SHOULD have an active lifetime no longer
than five minutes.
– Source:
https://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.2

I believe I had seen that last recommendation elsewhere in OpenID Connect
specs (probably earlier drafts of the Core spec, back when it was split in
several documents), and that was what motivated my question months ago
(actually more like two years ago I believe) related to the Session
Management draft.

My interpretation is that Session Management actually is wrong recommending
using the ID Token expiration as a baseline for session expiration. Can
someone please confirm?
(if you prefer I instead create an issue at BitBucket, I can do that too)

On Tue, Feb 16, 2016 at 2:40 AM Mike Jones <Michael.Jones at microsoft.com>
wrote:

> FYI
>
>
>
> *From:* Mike Jones
> *Sent:* Monday, February 15, 2016 5:39 PM
> *To:* openid-specs-heart at lists.openid.net
> *Subject:* HEART Implementer’s Drafts Approved
>
>
>
> The following notice was posted at
> http://openid.net/2016/02/15/heart-implementers-drafts-approved/:
>
>
>
> *HEART Implementer’s Drafts Approved*
>
> The OpenID Foundation members have approved of the following
> specifications as OpenID Implementer’s Drafts:
>
> ·       Health Relationship Trust Profile for OAuth 2.0
>
> ·       Health Relationship Trust Profile for OpenID Connect 1.0
>
> ·       Health Relationship Trust Profile for User Managed Access 1.0
>
> An Implementer’s Draft is a stable version of a specification providing
> intellectual property protections to implementers of the specification.
>
> The specifications are available at:
>
> ·       http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html
>
> ·       http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html
>
> ·       http://openid.net/specs/openid-heart-uma-1_0-ID1.html
>
> The voting results were:
>
> ·       Approve – 34 votes
>
> ·       Object – 1 vote
>
> ·       Abstain – 11 votes
>
> Total votes: 46 (out of 204 members = 23% > 20% quorum requirement)
>
> — Michael B. Jones – OpenID Foundation Board Secretary
>
>
> _______________________________________________
> 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/20160222/2e68ded5/attachment.html>


More information about the Openid-specs-ab mailing list