[Openid-specs-ab] Fwd: New Version Notification for draft-hunt-idevent-token-02.txt

Vladimir Dzhuvinov vladimir at connect2id.com
Tue Aug 16 15:55:36 UTC 2016


Hi Phil,

The spec appears well structured. Putting "sub" into an unambiguous
context was a great idea!

I have a question about the proposed format:

Each event in the "events" array is an URI, and may be enriched with
extra info / context represented as a top-level JSON object that has the
event URI as key. What if the issuer needs to emit multiple events with
identical URIs in the "events" array, and they all require an additional
context?


{
     "events":[
       "https://example.com/event-abc",
       "https://example.com/event-abc"
     ],
     "https://example.com/event-abc":{
        "xyz":5
     },
     "https://example.com/event-abc":{
        "xyz":10
     }
}


Vladimir


On 12/08/16 00:52, Phil Hunt via Openid-specs-ab wrote:
> This is an updated draft and contains a lot of the items from the discussion today.
>
> Based on feedback from OpenID RISC and Connect WG calls, I have moved the “sub” in the examples to the event extension area. This allows each event spec to decide how they define or address a subject. It also avoids conflicts around “iss” when the event issuer is not the namespace of the “sub” claim.
>
> The examples now show a consistent parsing pattern where the top level of the JSON structure is essentially an “envelope” that describes and validates the event from a publisher to a subscriber, and the nested JSON objects are the “payload” for the event.
>
> The spec has been renamed to Security Event Token as part of making the terminology more consistent and to reflect that some events are not specifically about identity but are about other related things like IP addresses, sessions, tokens, web resources etc.
>
> I recognize we don’t yet have consensus on this draft, but I’ve gone ahead and published draft 02 so the broader community can compare draft 02 with draft 01 to see the differences in event formats.  I expect to see more changes as the discussion continues.
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com/>phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>
>
>
>
>
>
>> Begin forwarded message:
>>
>> From: internet-drafts at ietf.org
>> Subject: New Version Notification for draft-hunt-idevent-token-02.txt
>> Date: August 11, 2016 at 1:25:50 PM PDT
>> To: "William Denniss" <wdenniss at google.com>, "Phil Hunt" <phil.hunt at yahoo.com>, "Morteza Ansari" <morteza.ansari at cisco.com>
>>
>>
>> A new version of I-D, draft-hunt-idevent-token-02.txt
>> has been successfully submitted by Phil Hunt and posted to the
>> IETF repository.
>>
>> Name:		draft-hunt-idevent-token
>> Revision:	02
>> Title:		Security Event Token (SET)
>> Document date:	2016-08-11
>> Group:		Individual Submission
>> Pages:		15
>> URL:            https://www.ietf.org/internet-drafts/draft-hunt-idevent-token-02.txt
>> Status:         https://datatracker.ietf.org/doc/draft-hunt-idevent-token/
>> Htmlized:       https://tools.ietf.org/html/draft-hunt-idevent-token-02
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hunt-idevent-token-02
>>
>> Abstract:
>>   This specification defines the Security Event token which may be
>>   distributed via a protocol such as HTTP.  A Security Event Token
>>   (SET) is based on the JSON Web Token and may be optionally signed
>>   and/or encrypted.  A SET describes a statement of fact that may be
>>   shared by an event publisher with registered subscribers.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-- 
Vladimir Dzhuvinov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160816/71b11865/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3711 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160816/71b11865/attachment.p7s>


More information about the Openid-specs-ab mailing list