What is the subscription validation event message schema in azure event grid?

Question

1. Created new azure event grid domain with cloud event schema using portal.
2. Created new web hook endpoint using azure function that can receive both subscription validation event as well as event notifications.
3. Created new azure event grid topic for the above domain (as part of following subscription) using portal.
4. Created new azure event grid subscription with cloud event schema with the above web hook endpoint.
5. When the subscription is Created, the endpoint was invoked by the grid infrastructure with subscription validaiton event to verify web hook endpoint.

To my surprise, the validation event structure (shown below) seemed to conform to native event grid schema and not cloud event schema:

[{
    "id": "6309ef83-117f-47aa-a07c-50f6e71a8ca5",
    "topic": "/subscriptions/13ad1203-e6d5-4076-bf2b-73465865f9f0/resourceGroups/xxxx-sandbox-rg/providers/Microsoft.EventGrid/domains/eg-xxx-test-cloud-domain/topics/eg-xxx-test-cloud-topic",
    "subject": "",
    "data": {
        "validationCode": "391889BB-FCC3-4269-A2BD-0918B5BAB0AE",
        "validationUrl": "https://rp-westus.eventgrid.azure.net/eventsubscriptions/xxxx-subscription-3/validate?id=391889BB-FCC3-4269-A2BD-0918B5BAB0AE&t=2019-01-30T15:45:37.0521594Z&apiVersion=2018-09-15-preview&[Hidden Credential]"
    },
    "eventType": "Microsoft.EventGrid.SubscriptionValidationEvent",
    "eventTime": "2019-01-30T15:45:37.0521594Z",
    "metadataVersion": "1",
    "dataVersion": "2"
}]

I expected following subscription validation event that conforms to cloud event schema (based on the 0.1 version of cloud event schema at https://docs.microsoft.com/en-us/azure/event-grid/cloudevents-schema#cloudevent-schema ):

{
    "eventID" : "6309ef83-117f-47aa-a07c-50f6e71a8ca5",
    "source" : "/subscriptions/13ad1203-e6d5-4076-bf2b-73465865f9f0/resourceGroups/xxxx-sandbox-rg/providers/Microsoft.EventGrid/domains/eg-xxx-test-cloud-domain/topics/eg-xxx-test-cloud-topic",
    "data": {
        "validationCode": "391889BB-FCC3-4269-A2BD-0918B5BAB0AE",
        "validationUrl": "https://rp-westus.eventgrid.azure.net/eventsubscriptions/xxxx-subscription-3/validate?id=391889BB-FCC3-4269-A2BD-0918B5BAB0AE&t=2019-01-30T15:45:37.0521594Z&apiVersion=2018-09-15-preview&[Hidden Credential]"
    },
    "eventType" : "Microsoft.EventGrid.SubscriptionValidationEvent",
    "eventTime" : "2019-01-30T15:45:37.0521594Z",
    "cloudEventsVersion" : "0.1",
    "eventTypeVersion" : "2",
}

What am I missing thing?

Answer 1

Basically, the webhook subscriber is handling the following two groups of the events. The specific event type is stored in the http header 'aeg-event-type'.

1. Internal events of the Event Grid model such as the eventTypes SubscriptionValidation and SubscriptionDeletion . The schema for these event types are always the same as a default schema such as an EventGridSchema . In other words, it's not depended on the EventDeliverySchema . IMO, having the default schema for internal events is making a strong event types specially when we have a CustomInputSchema.

2. Interest source events (topics) are events defined by input schema and presently the Event Grid model supports 3 types such as EventGridSchema (default), CloudEventSchema and CustomInputSchema . The AEG supports the following schema input/output mappings:

   1. EventGridSchema to delivery schemas EventGridSchema and CloudEventSchema
   2. CloudEventSchema to delivery schema only CloudSchemaSchema
   3. CustomInputSchema to delivery schema EventGridSchema and CloudEventSchema and CustomInputSchema

   The event type in the header is: aeg-event-type=Notification and the schema is based on subscribed EventDeliverySchema (see the following mappings).

Based on the above, for your scenario you should have a separate strong type objects for Internal events (default schema is EventGridSchema) and for Notification events based on the subscribed EventDeliverySchema.

The following is an example of the http headers:

aeg-subscription-name=EVENTGRIDSCHEMA
aeg-delivery-count=0
aeg-data-version=
aeg-metadata-version=0
aeg-event-type=SubscriptionValidation

Note, there is only a subscription name to figure out which an EventDeliverySchema has been subscribed. It will be nice to have an additional aeg header for example: aeg-subscription-labels to pass some subscription metadata to the subscriber handler.

As a workaround, we can pass to the subscriber webhook handler some values via the url query parameters, for instance: &eds=CustomInputSchema

Answer 2

This is a known issue / expected behavior in the Azure Event Grid implementation of Cloud Event V0.1 spec. At the time Cloud Events v0.1 spec was implemented in Azure Event Grid, there was no validation handshake / abuse protection model defined in the Cloud Events standard and hence Event Grid's existing validation handshake model/schema was used for Cloud Event subscribers as well.